1 Dealing with the longer term 2
1.1 Introduction 2
1.2 Avoiding Y2K type problems until A.D. 10000 4
1.3 Extending the calendar beyond A.D. 9999. 6
1.4 Lack of a fixed long term relationship between years, days and seconds 7
1.5 Calculation of effects of rates of change between A.D. 1600 and 10,000 9
1.6 What should a long term calendar be 13
1.7 Possible coexisting alternate administrative periods and reforms 14
1.8 Managing nearly continuous universal availability of accurate UTC 16
1.9 Coordination with sidereal time, etc 18
1.10 Automatic date/time synchronisation and subroutine updates 19
1.11 General adoption of the SQL date handling facilities 22
1.12 Adopting SQL date handling routines for COBOL, etc. 25
1.13 Practical aspects of implementing a date/time subroutine 28
1.14 Potential changes to ISO 8601, Representation of dates and times in information interchange 29
1.15 Potential changes to Rec. ITU-R TF.460-5, Standard-frequency and time signal emissions and related standards 34
1.16 Desirable practices and pitfalls 35
1.17 Not trying to do too much too soon 37
1.18 Legal aspects 38
1.19 Glossary 39
1.20 References 56
2 Ideas and Work in progress 66
2.1 Leap seconds and durations 66
2.2 Calculations involving months 66
2.3 Practice and thoughts on Timestamp arithmetic 66
2.4 Accuracy indicators 67
2.5 Delay in application of timestamps 67
2.6 Julian Days 68
2.7 Potential date/time and duration representation 69
3 Correspondence 71
1 Dealing with the longer term
1.1 Introduction
Ideally, this discussion would explain standards for hardware and
software that could handle an eternal calendar, whatever that is, should
be or can be. This would involve semi-automatic radio updates for
forthcoming national holidays, leap seconds, leap years, and long term
variations in the relationships between SI seconds, mean solar days and
tropical years. Even if all religious holidays were fixed, there would
still be the occasional need for unexpected public holidays. It is much
better to be able to vary the dates of such events at will, though
calendar software would be simpler, more efficient and more likely to be
correct if most were fixed, or at least easier to calculate. The facility
to automatically revise the use of calendar months and weeks may also be
useful, so may the ability to introduce new administrative periods such as
decimal multiples of seconds. The simultaneous provision of sidereal time
for navigation and related activities should be considered. A four digit
windowing mechanism would probably be necessary for the representation of
dates in external formats. The need to be able to apply corrections should
not be overlooked as it would be rash to presume that mistakes would never
be made.
I have to admit that several aspects are probably beyond my
capabilities, especially those involving non-stop real-time
instrumentation. Advancing hardware and software technology has made
dealing with some aspects easier. There is also the probability of future
unforeseen advances that may make some approaches obsolete. The best
defence against this is the universal handling of dates, times and
durations by subroutines in various guises, such as standard functions,
subprograms, copybooks and object classes. This would make it easier to
apply future changes with minimal interference to the smooth running of
existing systems.
It is arguable that one should not try to do too much too soon, but it
is important to make potential future changes easy to apply. The
application of leap seconds should be handled properly in calendar
software as soon as possible, since though rare, the potential problems
are progressive. I realise that this would make calendar software slower
and more complex, also that in some cases guidance notes for use would be
needed in addition. For example, when comparing two timestamps to
determine a duration in whole days or years for administrative purposes,
it is usually desirable to extract the date components of the timestamps
for use as the basis for the comparison. Obtaining both time and calendar
updates by radio is another subject that should be dealt with soon.
I think that a solution would involve both hardware and software.
Regular UTC time signals are already available via radio and RDS makes
them even easier to obtain. Computer clock speeds could be synchronised
with the time signal in suitable multiples or subdivisions of the
precision available over radio links. I think that they could be designed
to be self calibrating with a memory of needed adjustments under varying
conditions that would enable them to maintain good accuracy during
disruptions to a radio link. Calendar rules could be provided in tabular
form, transmittable by radio. So with careful design, the software would
be relatively insulated from the need for alteration, those components
that potentially need changing could be encapsulated to make replacement
easy. To reduce execution time overheads, dates and times near to the
current date could be processed using special reference points in the
tables to minimise the calculations needed. Most computer systems wouldn't
need the full range of date facilities for a full range of dates, so could
perhaps reference a networked system on the rare occasions when they are
required, thereby allowing the local storage and software requirements to
be minimised and for the specialist facilities to be more comprehensive.
A common approach to handling dates, times and durations has the benefit
of ensuring that individual systems comply with required standards. This
is one of the major problems in dealing with the Y2K situation.
1.2 Avoiding Y2K type problems until A.D. 10000
For the longer term, I think that it is desirable that all systems and
archive data should be designed to at least nominally be valid until A.D.
9999. Ideally they should be able to be perpetuated beyond that date with
minimal or no difficulty. Currently, there are several systems in use that
will have a date rollover at various times not very long after A.D. 2000.
This is especially important when considering systems built up from a
variety of hardware and software components provided by several suppliers,
where there could be several different rollover events on differing dates,
anyone of which could cripple a whole system and some of which might not
even be documented.
It would be possible to develop date routines using four year digits
with a sliding window, in the same way that such schemes are used for two
digit years. Whether this would be a good idea is open to question.
I think that a general principle of WYSIWIG should be applied, so that
when a number representing a value is stored in a computer system,
including external storage media, then the internal computer
representation should be capable of storing all reasonable potential
values associated with the external representation, or should be easily
extendable to do so. While there was good reason for minimising data
storage in the very early days of computing, this is no longer so critical
for representation of simple data values, any exceptions should be subject
to approval and documented. Serial numbers are another example of a field
type that would be better for being open-ended.
In some cases, it might be more helpful for components to have a known end of use date, similar in concept to a sell-by date. Some components would instead
perhaps have a defined reset period, these would be those that contain
time-keeping counters of very limited capacity or accuracy. Apart from
being specified in their documentation and a summary stamped on their
exteriors, these components would also identify their limitations to
assemblies and systems that incorporate them. While microprocessor
memories in computers are now very capacious and versatile, there are
classes of very simple microprocessors for which an associated radio clock
mechanism would be impractical.
I also think that it is generally desirable for systems to be tested for
their longevity. To do so would require the ability to intercept date and
time activities using a special test version of the calendar software,
which could itself be the subject of a standard. One would expect such
tests to cover the projected lifetime of the system with a generous margin
for overrun.
One should be aware that, according to the Encyclopaedia Britannica, for
a system that is to work until A.D. 9999, years divisible by 4000 should
not be leap years and that such adjustments will be accurate to within a
day to about A.D. 20,000. The Royal Greenwich Observatory says that the
Gregorian calendar provides about three too many leap years over 10,000
years. My own calculations suggest that even fewer leap days would be
necessary, so adjustments would be needed more frequently. There would be
further regular and perhaps some irregular adjustments to be made over
much greater periods, some with increasing frequency, though not
necessarily all in the same direction. It is arguable that date routines
do not presently need these additional adjustments, though good design
should make them easy to apply, when the accuracy of their application
would be more precise. My own calculations suggest that the first would be
needed around A.D. 4000 and that a further six would be needed before A.D.
10000.
One should also be aware that with the gradual increase in day length,
there will be a need for about 60 leap seconds per year in the year
10,000. Even in A.D. 2100 there would be a need for almost twice as many
leap seconds.
The occasion of A.D. 10000 could be regarded as an opportunity for a
good spring clean of computer systems and a review of year, day and second
relationships at the appropriate time, when it is to be hoped that such a
task will be better planned and coordinated. Arguably, it is highly
probable that a catastrophic event sufficient to affect current
relationships would not have occurred in that period, though contingency
planning would be advisable.
1.3 Extending the calendar beyond A.D. 9999.
While it may eventually be decided that this is looking too far ahead, I
think that the subject should be considered, if only to help make it
relatively easy to do, when the time comes.
It would be possible to use a sliding window for four digit dates, a
generalised multi-digit windowing scheme might also serve this purpose.
Increasing the size of date fields on reports and screens could involve
substantial reworking, usually of fairly trivial nature, but nevertheless
highly inconvenient and awkward when data no longer fits an existing
space. Though in A.D. 9999, revising font sizes in large screen formats
can be expected to be relatively easy. However, it is usually easier and
faster to use fixed length formats rather than variable length formats for
data storage. Although fixed length formats can be converted and the use
of date datatypes will make this easier, there are still potential
problems with the manipulation of composite groups of data. It is probably
the case that many people will be even more reluctant to use five or more
digit year numbers, than they are now to use four digit year numbers.
Somewhat reluctantly, I conclude that for data storage of dates, the use
of variable length formats is the most durable and should be promoted.
This would make the use of data structures containing dates somewhat more
difficult in traditional programming languages and less efficient in the
relatively short term.
For screens and reports, one could use one, two, three, four or more
digit dates with a windowing mechanism, and ensure that a system makes it
clear in the context, which is intended and prompts users to confirm their
meaning when entering data.
Consequently, the manipulation and handling of dates would all have to
be mediated by subroutine, even for seemingly trivial activities, such as
transferring an already formatted date field to a screen display layout.
I am now tending towards the opinion that a four digit sliding
window could be a serious contender for administrative purposes, but will
have to think some more about it.
1.4 Lack of a fixed long term relationship between years, days and
seconds
Unless specifically stated otherwise, year is calendar year, day is
calendar day and second is SI second.
One must not presume that there is a long term definite fixed
relationship between tropical years and mean solar days, nor that their
individual lengths will remain constant. While a day normally contains
86400 seconds, the SI second has for about forty years been defined as
being of an unvarying length, defined by various techniques based upon
atomic physics. (It may have been defined as being of a fixed length even
earlier, but I haven't yet found such a definition.) Consequently, leap
seconds have been regularly applied to UTC about once a year since 1972.
While it is expected that leap days and seconds will continue to be
additive, this should not be assumed.
Overall, the length of a tropical year is slowly decreasing and the
length of a mean solar day is slowly increasing, while the SI second is
defined in such a way as to be nearly a fixed constant with only cyclic
changes.
It may well be that the rates of change are not themselves constant.
It can not even be assumed that changes in the relationships will be
gradual at a steady rate, though only catastrophic events would cause
major discontinuities in the already known long term rates of change.
There are some very long term astronomical effects that affect the
Earths's orbit in a periodic fashion. There are also various factors that
have a short term effect on rotation. These are compelling reasons for
always using a date routine to handle comparisons and calculations, since
a date routine can be modified with relative ease compared with having to
change a multitude of programs.
One should consider the possible effect of any major meteor strike or
near miss upon the Earth's rotational period and orbit. This would
probably be relatively small, but even so could be enough to cause
significant disruption to our current timekeeping standards. Even a
substantial lunar impact may have an effect upon the Earth's rotation, by
affecting the Moon's orbit. Such events might also result in a higher
level of variability in these periods, especially in the immediate
aftermath of such a catastrophe. This could necessitate a revision to
calendar rules and ideally a date handling system should make provision to
accommodate such changes gracefully. Whether such impacts increase or
decrease year and day lengths would presumably depend upon the direction
of approach relative to the Earth's orbit and spin.
I must admit that I don't know whether the sort of meteor impacts that
seem to recur about every 26 million years would have a significant
effect, so this should be the subject of further investigation. For a
physicist or mathematician this would probably be a relatively
straightforward exercise, to be based on the relative masses and
velocities of meteors, the Earth and the Moon.
About 400 million years ago, there were 400 mean solar days in the
tropical year and the lengths of both were significantly different from
their current values. The mean solar day length was about 22 hours in
today's units.
It would be desirable to determine how gradual is the change in absolute
values and relationships. Some meteor strikes may have had a larger effect
on the Earth's rotation and orbit than the few seconds or less per year
that I would imagine. To determine this one would need to examine the
whole geological record with particular attention to the periods closely
preceding and succeeding such impacts. Corals preserve a record of both
annual and diurnal variations, so their fossil records might be worth
investigating for this purpose, I believe this may already be being done.
There may be other forms of deposit that could be used for this purpose as
well. It is probably unrealistic to hope for a continuous record through a
meteor induced catastrophe, especially if there were significant sea level
changes, the best one could hope for are records from deposits relatively
close to such events.
One could consider how the long term maintenance of TAI could be
preserved through a major meteor or comet impact. Perhaps this is an
argument for also having one or more atomic clocks and observatories based
upon the Moon or in satellites in stable orbits. I have since found that
there are some atomic clocks in satellites.
There is an argument for generally available independent standard
records to be maintained of elapsed tropical years, solar days and SI
seconds as counts from a common reference point. Maybe this should be a
service provided by the IERS, to be made available via the internet and
time signals. Julian days and TAI already provide a measure for mean solar
days and SI seconds. I must think about this some more, one problem is
determining a point at which the start of the tropical year and the start
of the solar day are truly or acceptably synchronous, e.g. 1958, January 1
at 00.00 hours, for day and second. It may be that an arbitrary date can
be chosen, even if in the future, and earlier dates can be internally
represented as negative values. A historical reference point is to be
preferred even if earlier than accurate record keeping, provided that
acceptably accurate extrapolation is possible. Some people have argued
that the primary reference point should be at some time before the big
bang event in the observable universe. However, even this may not be
ideal, since relativistic effects would affect physical timekeeping over
such durations.
In a sense, most of the existing civil and some ecclesiastic calendars
achieve this already, though the arithmetic rules involved are complex
and, even so, don't presently account for changing relationships.
Two of the astronomers' ways of dealing with the variability of tropical
years and mean solar days are to use a Julian year of 365.25 days of 86400
SI seconds and to use Julian days.
1.5 Calculation of effects of rates of change between A.D. 1600 and
10,000
For administrative purposes it is necessary to maintain a satisfactory
relationship between average tropical years and mean solar days. A
calendar must measure tropical years in terms of mean solar days, despite
the fact that both will vary in the long term.
While it is arguable whether any current prediction of changes can be
sufficiently accurate for absolutely definitive practices to be based upon
it over such a long period, it is still advisable to assess the likely and
possible changes and consequences in order to design and implement
suitably adaptable and resilient date and time handling hardware and
software.
Year length in 1900 was 365.242196 days, in 2000 it is predicted that it
will be 365.242190 days, according to Encyclopaedia Britannica (under Time
not Calendar) in 1995 and 1997 and using days of 86,400 SI seconds. The
difference of .000006 days is equivalent to a decrease of 0.52 seconds.
Kaye and Laby 1986 and 1995, states that tropical year length is currently
365.242193 days of 86,400 SI seconds and is decreasing at about the same
rate as stated by Encyclopaedia Britannica, but with an extra place of
precision giving a value of 0.0000061 days.
Kaye and Laby states that the year for which a mean solar day is
86,400.003 UTC seconds was circa 1984. According to the given long term
rates of change and assuming that this day length is exact, then in 1900
the mean solar day would have been around 86,400.00132 seconds and in 2000
will be around 86,400.00332 seconds.
Day length is currently increasing by about 20 milliseconds per 1000
years, according to various reference sources, though Encyclopaedia
Britannica gives a figure of 16 milliseconds under Time and 20
milliseconds under Geochronology. In 1984 and 1995 it was 86,400.003
seconds and to three digits of precision will probably be the same in
2000. The difference made to my calculations for a value of 86,400.004
seconds was minimal. Another source indicates that the long term average
rate of increase is 23 milliseconds per millennium, but that glacial
rebound is affecting current values.
Encyclopaedia Britannica states that years divisible by 4000 should not
be leap years until the year 20000, when a further adjustment would be
needed. The Royal Greenwich Observatory web site in leaflet no 48 states
that the Gregorian calendar will have about three leap years too many over
a period of 10000 years. By taking into account both increasing day length
and decreasing year length, the following calculations indicate that there
would be seven leap days too many in the next 8400 years.
I have developed a formula to determine the effect of combined increase
in day length and decrease in year length. It calculates tropical year
lengths measured in units of the mean solar day of the date under
investigation.
0.0000061 days per century decrease in year length. This is mean solar
days of 86,400 SI seconds per Julian year. For these purposes, the Julian
year and tropical year can be assumed to be the same as the current
discrepancy is about one part in a million, so the effect on the factor
0.0000061 is well below the level of accuracy in its specification. The
effect of the difference between the current mean solar day and 86,400
seconds is also well below the level of accuracy of the factor. These
assumptions are true provided that the equation is used to work out
projections from close to the present, otherwise the factor must be
adjusted appropriately.
units are tropical years, mean solar days and SI seconds
a = no. of years ahead (positive) or past (negative)
b = current no. of days per year (365.242193)
c = decrease in year length per 100 years (0.0000061 days)
d = current day length in seconds (86,400.003 seconds in 1984)
e = increase in day length per 1000 years (0.020 seconds)
days/year = (b - (c/100 * a)) * (d /(d + e/1000 * a))
days/year = (b - (c * a/100)) * (d /(d + e * a/1000))
(The second form suits my spreadsheet better, as it reduces the
roundings problem with the divisions.)
A more comprehensive formula would contain factors for changes in the
rates of change if any, and would also accommodate factors for the
Milankovitch cycles. Incorporating these cycles would require a reference
to a specific base date for their synchronisation.
Integral calculus would provide a more accurate approach, but wouldn't
significantly affect my results for the period of 8400 years from A.D.
1600, given the margin of error allowed and that the rates of change used
are constant.
I checked my formula between the years 1900 and 2000 for which specific
year lengths are known, it agrees quite reasonably when the day lengths
are corrected for the difference between the calculated values and the
current mean solar day of 86,400 seconds. However, one should remember
that the difference in year length between the two dates will have been
subject to relatively short term periodic fluctuations.
As the Gregorian calendar was initiated in A.D. 1582, I have done
calculations from A.D. 1600 (the nearest round figure), when the effect of
deviation from the year length then calculated would have been minimal.
Using the Gregorian calendar, the number of days in the 8400 years to A.D.
10,000 would have been 365x8400, plus 24x84 ordinary leap days, plus 21
leap days due at the 400 year intervals. This totals 3,068,037 days, of
which 2037 days would be leap days. My calculations are based on the
period from the start of A.D. 1600 to the start of A.D. 10,000, i.e. not
8401 years.
20x8 = 160 milliseconds is the increase in day length projected for A.D.
10,000 at the rate of 20 milliseconds per 1000 years. Current solar day
length was 86,400.003 seconds in 1984. I am treating the difference
between day length in 1985 and 2000 as so negligible as to be safely
ignored, so projected day length in 10,000 would be 86,400.163 seconds.
Working backwards 400 years on the same basis, day length in A.D. 1600
would have been 86,399.995 seconds.
The number of days per year in A.D. 1600 would therefore have been
365.242251.
Similarly the number of days per year in A.D. 10,000 would be
365.241028.
Averaging the two gives 365.2416395 days per year for the period A.D.
1600 to A.D. 10,000.
Multiplying 0.2416395 by 8400 gives the number of leap days due in the
period, i.e. 2029.772, say 2030. This compares with the figure derived
from the Gregorian Calendar of 2037 leap days. It is also about two days
lower than shown by similar calculations excluding increasing day length.
Allowing for a spread in the rate of change in day length of between 15
and 22 milliseconds per millennium and with a rate of change in year
length of -0.0000061 days, the number of leap days required between A.D.
1600 and 10,000 would still be the same within half a day.
Similarly, allowing for a spread in the rate of change in year length of
between -0.0000039 and -0.0000069 days and with a rate of change in day
length of 20 milliseconds per millennium, the number of leap years
required between A.D. 1600 and 10,000 would still be the same within half
a day.
To remedy the potential excess of seven leap days between A.D. 1600 and
10,000, one could slightly revise the rules of the Gregorian calendar to
ensure that years divisible by 1200 would not be leap years, with the
exception of A.D. 1200, which is now in the past and predates the
Gregorian calendar anyway. Whether this should be done starting with the
year 2400 or the year 2800, which is 1200 years after 1600, would be open
to question. Another option is to explicitly make the years 4000, 5600,
6800, 7600, 8400, 9200 and 10,000 non-leap years as the requirement
becomes more frequent. These years are the multiples of 400 that most
closely match the dates at which the calendar would be a whole day adrift.
The latter option would also defer the necessity to make a change until
the trends can be more accurately determined. A related option is to make
the adjustments at the points where the discrepancies are just over half a
day. Waiting until the calendar is about a whole day adrift has the
benefit of allowing for the possibility that it might regress again due to
some astronomical or other effect.
Further changes would be needed for the period A.D. 10,000 to 20,000. In
the year 20,000, year length would be 365.239573 days. Averaging the year
lengths in 10,000 and 20,000 would give the value 365.240301. Multiplying
the fraction 0.240301 by 10000 gives 2403.005, which is the number of leap
days due in the period. The Gregorian calendar would have applied 2425
leap days, i.e 22 too many. This would necessitate deducting a leap day
every 454 years, so for that period it might be considered desirable to
remove the leap year due every 400 years as a reasonable approximation,
which would also cover the requirement for a further few thousand years.
On the other hand, since the rate of application would increase with time,
it may be preferable to deduct leap years as and when required. However, I
think that while it is necessary to look ahead, any decision as to what to
do should be deferred until the need arises, when the actual requirement
will be clearer.
For an even longer look ahead using the current rates of change, year
length would be 365 days around A.D. 1,900,000 and 364.25 days around A.D.
7,800,000. Also, looking backwards, year length would have been 400 days
between 230-260 million years ago.
Working backwards to about 400 million years ago, when geological
records (of corals) show that year length was 400 days (and day length is
estimated by methods unknown to me to have been about 22 hours), implies
an average shortening of year length by one mean solar day per 11.4
million years.
These two approaches only very roughly agree, so one must conclude that
either the long term rates of change have altered or they have not been
calculated sufficiently accurately. Reasons for their alteration might
include long term progressive effects, further as yet unknown long term
periodicities and one or more episodes in which either or both orbit and
rotation were altered significantly. Reasons why a long term average may
not have been calculated correctly could include not making allowance for
glacial periods, plate tectonics and climatic variations. If one were
confident that there were about 400 days per year 400 million years ago
and that my method of calculation is correct using current rates of
change, then it would be possible to calculate approximate past changes in
the rates of change. This might then be of use in estimating future
changes in the rates of change, though episodic disruptions of the nature
discussed below might make this more difficult.
According to some scientists, there would have been substantial meteor
impacts about every 26 million years, i.e. about fifteen such events, some
of which may have involved multiple impacts within a few hours for objects
similar to the Shoemaker-Levy comet or perhaps even thousands of years
apart for objects travelling somewhat further apart near the nucleus of a
meteor swarm. While such objects might tend to influence the Earth's orbit
in relatively similar directions, the way in which they might influence
the Earth's spin would probably be random. I believe that most asteroids
and comets have prograde orbits in much the same ecliptic (plane) as the
planets. However, it must be said that meteors might approach the Earth on
either the inward or outward leg of their trajectory around the Sun, so
their effects on the Earth's distance from the Sun could be variable in
nature. While the effect of a meteor impact on the Earth's orbit and
rotation would in itself be very small, it might still have a significant
effect on timekeeping, especially over the long term. If the velocity of
even small meteors and comets is non-random, then there may be a
cumulative long term effect.
Ice ages might also have a significant effect upon rotation by their
influence upon the atmosphere and terrestrial weight distribution,
isostasy mitigates weight distribution, but takes a long time to act.
Other long term climatic and oceanic current changes may also have an
influence, as may the distribution of land masses by plate tectonics,
periods of extensive volcanism and ratio of land to sea. Magnetic pole
reversals might produce temporary anomalies through various effects on the
atmosphere and ionosphere. The gradual accretion of cometary dust and
meteorites may have an effect, though that is probably already factored
into the current calculated rates of change. The escape of atmospheric
hydrogen might need consideration. Also consider possible changes in the
relative rotation rates of the Earth's core, mantle and crust, these might
be influenced by magnetic pole reversals. All these factors (and perhaps
some others unknown to me) need to be considered when trying to determine
average rates of change and changes in those rates of change over periods
of tens of thousands of years and more.
At present rates of change, in about 70 million years there will be a
need for 61 seconds per minute. In about 50,000 years there will be a need
for one leap second per day. In A.D. 10,000 there will be a need for about
60 leap seconds per year, while in A.D. 2100 there will be a need for
about two leap seconds per year.
The rates of decreasing year length and increasing day length may vary
in the very long term, though none of my calculations have considered
this. It may be the case that astronomers are already able to calculate
long term orbital changes and decreasing rotational spin rates, so could
provide better projections.
1.6 What should a long term calendar be
The somewhat philosophical question of "What is an eternal
calendar, what should it be or can it be?" should be tackled. While I
suppose there is no definitive answer, there are some practical aspects
that should be considered. At the simplest level, one is looking for a
consistent means of recording and specifying time indefinitely.
TAI, which is a record of SI seconds, is the simplest form of calendar,
though there can be no absolute guarantee that one second is equal in
length to another. In practice, the SI second is a compromise between less
than perfect uniformity and the need to provide an instanteously available
scale.
For the purposes of enabling society to coordinate our lives with the
tropical year and mean solar day, a more complex arrangement is required.
The Julian and Gregorian calendars were intended to provide a definite and
usable relationship between tropical years and mean solar days, while the
second wasn't a reliably measurable subdivision until the seventeenth or
eighteenth century and couldn't be used as a basis for long term record
keeping until the late nineteenth or twentieth century. The Julian and
Gregorian calendars were natural products of man's development of a
calendar that accurately correlates mean solar days and tropical years,
they were both acceptably accurate in their time. The Gregorian calendar
still is, but will eventually need further revision to accomodate the
residual inaccuracy in the current application of leap years, the
decreasing length of the tropical year and the increasing length of the
mean solar day.
The introduction of the S.I. second has complicated matters, so now an
administrative calendar has to correlate tropical years, mean solar days
and SI seconds. Although seconds were originally introduced as a fixed
subdivision of a minute, it is now clear that as the mean solar day is
gradually lengthening, the number of seconds per minute will gradually
increase. As the need for leap seconds is currently very infrequent, so
far the discrepancy for timekeeping in computer systems has not been very
significant for commercial applications. General purpose computers are
usually periodically reset and in my own experience do not and have not
needed to keep particularly accurate time anyway. (I feel sure that there
must be some applications already in use where the long term maintenance
of accurate time is important.) This can be expected to change, even in
the near future, so it is desirable to consider the effects carefully when
developing computer hardware and software to avoid several more Y2K types
of debacle.
One must also consider the long term requirements. On the one hand, it
can be expected that Earth will be habitable for around another 1000
million years, on the other hand, it can be expected that space travel
will become normal, assuming we survive as a species, genus or family for
long enough. The requirements of suitable calendars for both prospects are
not necessarily identical. In 1000 million years there would be around 250
mean solar days to the tropical year and 75 SI seconds to the minute. For
space travel with settlement on several planets, it may be that a 360 or
420 day year with no leap seconds or leap years would be the most
convenient common form, with suitable local variations appropriate to the
individual planets.
1.7 Possible coexisting alternate administrative periods and reforms
In the very much longer term, because of the vagaries of solar days and
years, it may be desirable at some future date to define administratively
convenient periods based upon decimal multiples of SI seconds. It might be
that, when or if the world's population becomes substantially less
directly involved in agriculture, a system not tied to the seasons could
be adopted. However, unless we mostly become trogdolytes, space travellers
or inhabitants of other planets, it is hard to see the tropical year and
mean solar day losing their social importance despite their variability.
Even on other planets, when or if we get to them, the local day and year
may still be the main social time basis. It is also the case that we have
internal biological clocks, which, though adaptable up to a point, would
still probably require a physiological day in the order of 24 hours, plus
or minus a couple of hours. Long term evolution could probably produce
physiological adaptation to shorter or longer days, provided medical
science allowed it. However, we do seem to manage quite well with weeks
not matching monthly and annual periods, so similarly, we may be able to
have separate administrative periods coexisting with days, weeks, months
and years. Such periods might be applicable to finance and technical
administration in the everyday workplace, though not so as to alter the
industrial or social working day, week, month or year. The biggest
obstacles are justification for the present system, the questionable
potential future benefit, the disruption that any change would involve and
social inertia.
Several organisations define their own administrative periods based upon
week numbers. ISO 8601 specifies that for yearly week numbering, week
number one is that containing the first Thursday of the year, it also
specifies that the week starts on Monday. There could also be an argument
for the weekly equivalent to a Julian day number, which should probably
start from the same base date, with an adjustment for the difference
between the Christian and Business first day of the week and the
difference between the Julian and Gregorian calendars. A modified Julian
week could also be adopted. Week numbering can also be defined
individually for specific projects, applications and organisations.
The TAI record of SI seconds has been maintained since 1972 with
accurate extrapolation back to 1958, negative values are used for earlier
dates. CORBA uses a record of UTC seconds that starts from zero at
00.00.00 on 15th October 1582, at the same time that the Gregorian
calendar was first implemented.
Several calendar reforms have been proposed and not adopted. It is a
field fraught with problems, since any system will be subject to long term
discrepancies. Having had various opinions, it now seems to me that the
benefits of major change to the administrative calendar are probably not
worth the disruption that change would cause. Any suggestion that months
should not be of roughly equal lengths probably wouldn't be appreciated by
the business community, or anyone who is paid monthly. I think that
administrative and social inertia make it unlikely that any major change
will be made to the ordinary calendar in the near future. Inertia can have
a derogatory meaning, I do not intend it in that way, but rather in the
sense used by Physics.
Another reform might be the full universal adoption of UTC and abolition
of local time zones for general administrative and social activities.
In practical terms, a revised calendar would depend upon nearly
unanimous international approval and the willingness to make the change.
It would introduce new problems, in particular the relationship of
historical dates to the new calendar, this could cause significant
administrative problems over several decades, which would continue to be
important, at least until all people living at the time of the change had
died. It might be the case that a calendar reform would be most easily
applied once all administration is done with computers and the date
handling of those systems is relatively stable. Perhaps it also needs the
large majority of the population to have easy regular use of computers for
their everyday activities. Then all conversions between new and old
calendars could be handled automatically.
One should note that hours and minutes are considered administratively
to be exact subdivisions of a mean solar day, with 24 hours per day and 60
minutes per hour, while there may be sixty or sixty one seconds in a
minute. I would expect that this relationship would continue indefinitely
with an ever increasing number of seconds per minute in the long term,
though there is a contingency provision to enable leap seconds to be
deducted in the event of what would probably be relatively short term
fluctuations. For space travel, a calendar based upon a fixed 60 seconds
per minute and 365, 360, 400 or 420 days per year might be considered
desirable, to coexist with that used on Earth and any new calendars that
may be devised for accomodating human life on other planets. A year of 420
days would have the benefit of accommodating whole weeks as well as also
being divisible by 3, 4 and 5.
It is highly desirable for a timekeeping system to accommodate the joint
needs of society, government, commerce, engineering, navigation and
science, even now they all use general purpose computers for much of their
work. Such a system should also accommodate the general public and, so far
as is reasonable, historians.
1.8 Managing nearly continuous universal availability of accurate
UTC
There is a strong argument for all computer systems to use automatically
updated Coordinated Universal Time (UTC) for all administrative date and
time recording, with or without timezones. It can be expected that in the
not too distant future most computers (and maybe even wrist watches, which
will probably evolve into microcomputers) will regularly obtain time from
an internationally coordinated national clock over a radio link. It will
also be the case that, with increasing sophistication of computer
facilities and applications, many more people and organisations will have
a need for accurate long term timekeeping in seconds that can be
accurately converted to dates and times appropriately adjusted for
time-zone and daylight saving time. For example, online computer
maintenance, upgrades and performance analyses by suppliers might be more
easily applied if both the host and the client are running with the same
date and time. (Perhaps not such a good example!!)
With increasing international networking, there is an argument for all
computers to use UTC without timezones for all internal and networked
activity, converting to appropriate timezones for display purposes only. I
would imagine that international airlines already do this, so it could be
beneficial to draw upon their experience and that of other organisations
operating internationally or across several timezones simultaneously.
It must be noted that there is a considerable distinction to be made
between equipment such as general purpose computers, often with
multitasking operating systems, being used for a variety of applications
and equipment being used to obtain precise, coordinated time and measure
very precise time intervals in scientific experiments, navigation and
engineering applications.
At present many computers, at least most of the mainframes that I have
worked upon as well as my own personal computers, do not keep or need
particularly accurate time, sometimes being as much as several minutes
adrift. It can be expected that this will change as accurate time becomes
readily and regularly available, when it will eventually become taken for
granted by most people. I have a personal radio that gets it every minute
via RDS, so easily applied, inexpensive technology is already available.
This will make the effect and application of leap seconds more
significant, especially as many more systems will gradually require the
need to be run non-stop.
With regular time checks, radio clocks can be designed to be self
calibrating, to improve their accuracy when communication with a time
signal is disrupted.
Portable computers and equipment in vehicles such as aircraft and ships
would have to be able to automatically seek the closest station
transmitting time signals, with allowances being made for possible
reception problems and transmission breakdowns.
While it is arguably desirable and good practice for computer systems
not to depend unnecessarily on accurate time for concurrency, it is not
difficult to imagine a set of computers in a network doing parallel
related tasks and using timestamps, while not necessarily all being in
radio contact with a common time reference, or with each other, except
when needing to communicate results and obtain fresh instructions and
data. For example, in oceanography and mining it would probably be normal
for some computers in a work group to be out of radio contact and not
connected to the network for part of their operation. Temporary radio and
network malfunctions could also be a potential cause of problems as the
affected computers or networks would probably be required to continue
operation and automatically resynchronise on reconnection.
There are practical problems in providing accurate time to applications
run on a multi-tasking computer, since any application may be interrupted
for an indefinite period. While the timer/clock facilities can be given a
high priority to limit delays, this can only provide the operating system
with accurate time up to limits imposed by its speed, architecture and
frequency of interrupts. Applications can be further subjected to
considerable delays because of resource conflicts and waits for user
responses. Multi-tasking control methods can limit conflicts between
different applications, but cannot protect against delays in multi-user
applications where data is being shared.
(Note that my knowledge of real time systems and interrupts is minimal.
I understand that they generally avoid the use of interrupts because
interrupts make programs non-deterministic and non-provable, according to
Mike James of Computer Shopper. A program that has interrupts has a high
probability of containing bugs that appear to occur randomly due to race
conditions in the hardware and software. Apparently, the US DOD insisted
that ADA didn't have interrupts and many mission critical real-time
processors leave out interrupts for the same reason. Also a multitasking
operating system does not have to use interrupts. IBM's OS/390 mainframes
and IBM PCs use interrupts, as do many other operating systems, in fact I
don't personally know of any that don't. From subsequent issues of
Computer Shopper, it seems that Mike James was mainly referring to the use
of interrupts in high level languages.)
Ideally, UTC should be maintained on a computer in such a way that
corrective adjustments can be made invisibly to most, if not all
applications, certainly most commercial and personal ones. Except perhaps,
for the application of leap seconds, which arguably are not corrections,
but a rare though necessary part of proper timekeeping. This requires the
definition of UTC maintained by the computer's clock to be at a more
precise level than that made available to applications, which for online
programs involved in human interaction would be relatively easy. As
corrective adjustments should be comparatively rare, a slight interruption
in the activity of running applications, to prevent ambiguous timestamps,
would not be significant in most cases. For computers that have clock
cycle rates faster than the resolution of time that can be maintained
accurately over a radio link, internal extrapolation would be required and
an accuracy indicator set appropriately.
1.9 Coordination with sidereal time, etc
Sidereal time is important for navigation and astronomy. While I don't
know the details, it is needed for the GPS system and is maintained on the
GPS satellites as coordinated from ground stations. As notebook computers
acquire more facilities one could expect them to incorporate GPS receivers
as a standard feature within a few years. GLONASS, the Russian
navigational satellite system could be used similarly and has the benefit
of not degrading the time signals provided.
In any case, the general availability of UT1 would be a benefit for
traditional position finding by sextant.
The existing time signal transmissions already provide DUT1, which is
the difference between UTC and UT1.
The provision of data on lunar periods and those of the other planets
could be considered as an ancilliary service.
1.10 Automatic date/time synchronisation and subroutine updates
A date routine could be developed to regularly obtain the current time
from the nearest national clock in conjunction with hardware involving a
radio or telephone system (or either interchangeably), with or without a
satellite link. Perhaps such a technique ought to be the subject of a
standard to make automatic allowance for such items as the type of
transmitter, the distance from the transmitter and internal circuitry
delays to permit synchronisation up to a user definable level of precision
within natural physical constraints. (There already is equipment that has
two way communication with atomic clocks to enable transmission delays to
be calculated and corrected for.) Using such facilities, updated software
for the date routine could even be automatically downloaded from the
national clock when occasion demands, such as a leap second or a change to
the standard.
Such a date routine would need a fail safe facility for situations in
which a radio or telephone link is disrupted or unavailable, for example a
notebook computer being taken to a remote location, such as abroad, far
into space, down a mine or just suffering from partial hardware failure.
International coordination would be essential. A mechanism to recover from
a total disruption to the power supply or system would be needed, such as
may be required for a major repair, major meteor strike, war damage,
sabotage, solar flare, flooding or earthquake, whether or not the link to
the national clock is then available on power-up. Such resynchronisations
would have to check for missed notifications of leap seconds, etc.
Mechanisms for the correction of disseminated errors should be
considered.
Certain measurement requirements would require a method of handling the
cases where equipment was being used to make very precise measurements or
local synchronisations that must not be disrupted by such standard
synchronisations, probably by allowing synchronised adjustment to be
triggered manually at a time to be determined by the equipment operator.
Use of a radio link generally has advantages over a telephone link, in
that there is no limit to the number of radio receivers that can receive a
message at the same instant, also there is no need for a telephone
connection, which would be much more expensive and problematic for those
systems that don't need or can't get a regular or permanent connection. A
telephone or cable link might be appropriate for situations where radio
links are impractical. National grid mains supplies could also be used as
a means for disseminating time signals, at one time many clocks did use
the mains to keep time. However, I don't know how reliable this would be.
The mains supply can also be used as a carrier for information services
and I believe some authorities are investigating its potential. However,
any network dependent upon long distance switched cabling is liable to be
subject to indeterminate propagation delays. LANs could conceivably be run
in synchrony with UTC in a similar fashion to individual computers and
would presumably take their cue from the servers.
Satellite links have the advantage of allowing more accurate
dissemination of time signals, since their distances can be calculated and
transmission delays more easily determined. The GPS system and other
satellites carry coordinated atomic clocks and are used to coordinate the
various independent national timekeeping services. The GPS system
maintains time in a cycle of 1024 weeks and does not incorporate leap
seconds. UTC can be obtained from the GPS system by anyone with a suitable
receiver, provided the current date and number of leap seconds to be
applied are also known.
However, the use of two way communication with the US GPS system would
probably be very limited, in part because it may be militarily sensitive,
large aerials would be necessary and such radio traffic could congest the
GPS system. The NPL is considering using the equivalent Russion GLONASS
system, which doesn't degrade the accuracy of time signals. The US has
indicated that it will cease to degrade time signals in GPS by 2005. There
are other satellite systems under consideration to provide cellphone
communication, these satellites would be in lower orbits, so receivers and
satellites wouldn't need such large aerials, two way communication would
be normal and the accuracy of the time signals disseminated would not need
to be artificially degraded. The facility for two way communication would
permit better assessments of transmission delays to improve accuracy.
However, I am not sure that cellphone satellites would carry atomic
clocks, though they could be used to connect to a service such as NPL
Truetime.
The ability to use more than one transmission method and source could be
regarded as a useful backup facility. For example, an unusually intense
period of solar activity could cause widespread disruption to satellite
links and radio communications.
The ability to simultaneously receive more than one time signal might
also be beneficial in reducing the risk of an individual source having any
defects. Receiving three such signals would permit a voting method to be
used to determine which is probably at fault when there is a discrepancy.
One might also argue that atomic clocks themselves should be run as sets
of three or more for the same reason. Within the limits of the accuracy
available from them, the system of 24 GPS satellites provides such
multiple redundancy.
Perhaps each computer should keep two sets of time, one based upon its
own internal clock to permit long term accurate interval measurement and
one that is coordinated with UTC. The determination of which time would be
used by a specific application or function would depend upon individual
requirements. Computer clocks are not currently as accurate as UTC anyway
and commonly drift far more than the amount of the occasional leap second!
Consider dual or multiple time recording within operating systems,
e.g. UTC and individual computer clock time, perhaps also locally
synchronised timekeeping for multiple processors within a single
functional computer system, such groupings may be permanent or temporary,
for processors built into the same unit or temporarily connected for a
specific multiprocessor application, e.g. individual local network time,
wide area network time, etc. Maybe each application, if run via different
networks, could have its own local time - raises more problems with
internal synchronisation between applications. SQL provides a potential
form of network time, though I don't currently know what happens to time
requests in a distributed database. On investigation, it would seem that
no synchronicity is explicitly provided, I would imagine that it is
considered impractical.
Perhaps what each computer should eventually have is a real-time clock
that is a semi-autonomous self-calibrating unit that is able to maintain
time in sychrony with a regular time signal, but with the ability to
operate in a standalone mode when the need arises. Such a unit would also
be responsible for providing calendar services and obtaining updates,
usually involving the notification of leap seconds and variable public
holidays. This would create a potential bottleneck if done directly, as
well as adding considerably to the amount of work required to service such
requests. However, it would make calendar updates easier to apply. Maybe
calendar updates should be supplied as a set of rules to be made available
in tabular form as a file that can be loaded into memory, for use by the
appropriate functions within individual applications. Maybe this clock
could be used to fine tune the frequency of the clock cycles of the
associated processors and buses to be a suitable multiple or subdivision
of SI seconds as supplied in UTC. My knowledge of processor architecture
and control is minimal, so experts would need to review and develop this
idea, if practical.
It would be desirable for any date fields transmitted with a time signal
to be specified as variable length for a potential unlimited continuity.
I understand that some transmitted time signal data contain two digit
year fields and similar limitations. Multiplexing would allow alternate
signals using a variable length format to also be transmitted to allow the
other forms to be gradually phased out.
It might be desirable to broadcast all forms of time kept by the various
international physical laboratories. In many cases, it would only be
necessary to broadcast the differences. Whether this would need to be done
on separate wavelengths or by multiplexing the information on a single
wavelength could be considered. Multiple wavelengths and transmitters
providing identical information, while more expensive, would provide some
redundancy to allow for equipment failures and maintenance. International
coordination of transmission content and format would help as discussed
below.
An international standard would be desirable to enable computers to be
taken almost anywhere and still obtain accurate time from one of the many
national clocks, using a facility like RDS to automatically search for the
strongest signals. Such a standard may already exist, but I am not aware
of it. Think about satellites and Global Positioning facilities,
plus space travel for which further problems apply even at relatively
moderate distances and speeds.
Most of the ideas I have floated (they are not necessarily only my own
ideas) would result in a substantially greater execution load for computer
functions involving dates, which is probably one of the reasons why they
haven't been adopted yet. While one must always keep an eye on efficiency
and try to maintain simplicity, it is also necessary to provide accuracy.
Current and future developments in computer speeds will lessen the impact
of increased execution load.
1.11 General adoption of the SQL date handling facilities
There would be considerable benefit in having a single common approach
to the handling of dates that is able to be incorporated by most, if not
all, programming languages. Such an approach would make it much easier to
ensure that all systems conform to required standards. SQL, which is a
facility to manage a relational database that is available to several
programming languages, could be an appropriate avenue. An object oriented
approach is another possibility. It would be possible to combine SQL with
an object oriented approach if so desired. A standard subset of SQL could
be used to provide calendar services without the relational database
features where they are not required.
One advantage of using SQL as the approach to providing date services,
is that SQL needs a date manipulation facility anyway for its relational
calculus, while many programming languages don't presently provide such a
facility, only providing current date and time. The alternative could be
multiple implementations of date handling procedures with the potential
attendant inconsistencies that could arise.
(I am now tending to think that more extensive reworking of the SQL date
handling would be required, while retaining consistency with the current
version. For example, it may be desirable to extend the formats in which
dates and times can be represented, to at least conform with all ISO 8601
formats, plus TAI seconds, Julian days and Modified Julian days.)
As already argued, there is a strong case for always using a subroutine
to mediate all date and time manipulations, since this provides a
relatively easy route for implementing amendments to apply revised rules
for dates and times. Here the term subroutine can be taken to include any
form of self contained, independent, invoked procedure within a program,
which may include functions, copybooks, object classes and independently
compiled subprograms. Within a program, SQL can be considered to be a use
of a subroutine, in that the behaviour of SQL can be changed independently
of the containing program.
There is a good argument for more generally adopting the practice of SQL
in which DATE, TIME and TIMESTAMP are defined as unique datatypes to be
used for the sole purpose of recording dates and times. SQL also ensures
that four digits are always used for the representation of years, a good
example of a standard that has anticipated the year 2000 problem. SQL
provides an arithmetic specific to these datatypes. It would be a function
of quality assurance procedures to maintain conformance. Up to two leap
seconds per minute are allowed. Summer time can be handled by the setting
of the time zone.
It would be expected that with these supplied datatypes, no other
type of date and time representation would be normally permitted.
Exceptions need to be made for week number recording and there may be a
need for year, year/month, year/day, Julian day, modified Julian day and
pure second formats. It may be that there would also be a need for
date/time representations for repeating events, e.g. month, week, day,
hour, minute and certain combinations. For example, a particular action
may need to be taken on or as soon as possible after the 5th of each
month, or 5 minutes past ten o'clock every morning.
SQL also provides datatypes for durations, which it terms intervals.
Intervals can be any contiguous set of YEAR, MONTH, DAY, HOUR, MINUTE and
SECOND, where there are two allowed groupings of: firstly, YEAR and MONTH
and secondly, DAY, HOUR, MINUTE and SECOND. When used in conjunction with
MINUTE, SECOND may not contain a value of more than 59.9(n), where n is
the defined precision. The handling of leap seconds in date arithmetic is
implementor dependent, which in the long term would be unsatisfactory.
There is no provision to allow the representation of a duration in the ISO
8601 format, except by use of both start and end dates. SQL interval
datatypes containing seconds are potentially ambiguous due to leap
seconds. My own view is tending towards excluding seconds from the
grouping of day, hour and minute and defining a new interval type for
seconds alone.
SQL leaves the internal representation and lengths of the datatypes to
the implementors. So it is possible to define them as variable in length
to permit indefinite expansion. Even when datatypes are defined as being
of fixed length, it is still relatively easy to redefine SQL column
lengths when the need arises, though host variables would be more
problematic. Good practice would tend towards date and time data-items
being typed, so their nature would be easily identifiable.
Where SQL date-time and simple or composite interval datatypes were used
in a program, manipulations and comparisons involving them would only be
permissible with SQL. They could be regarded as akin to the internal
numeric formats and implementors would have to specify what their physical
lengths would be for the purposes of allowing the length of record
descriptions to be calculated, etc. The existing external formats would
continue to be necessary to allow them to be involved in moves, input and
output with screens and files, etc.
The SQL standard specifies that the year component of a date must be
within the range 0001 to 9999 and that all such dates will be treated as
Gregorian dates, though the Gregorian calendar was first introduced in
1582 and was not adopted by all countries until early in the twentieth
century. This seems to be the most practical approach to avoid excessive
complexity within the SQL internals. Most pre-Gregorian dates are only of
academic relevance and systems that do need to account for them must
provide their own conversions. Development of an internationally
acceptable standard and software to do these conversions could be the
subject of a further study as an optional extra. If so desired, the range
of acceptable year values could be revised fairly easily.
It seems to be common practice to use 0001-01-01 and 9999-12-31 in date
fields to indicate dates that are as yet undetermined, while providing the
convenience of values that sort conveniently for ordering start and end
dates and are valid forms of date. This of course will cause problems
eventually, but as mentioned elsewhere, it could be expected that the next
rollover will be better planned and coordinated and that all existing
systems would have been redeveloped long before that becomes a problem.
However, since new systems usually build on older systems and have to
coexist with them for at least a few years, such problems could be self
perpetuating, as was the case for two digit year representations. It would
be conceptually preferable to have values that could be assigned to SQL
datatypes that could perhaps be described as NULL-HIGH and NULL-LOW, these
would have all attributes of a NULL value, but would allow suitable
ordering to be achieved and their very existence would have a meaning in
implying an indefinite past or future date. Tests for NULL-HIGH and
NULL-LOW would be permissible, while ordinary tests for NULL would work in
the usual way and include these new forms. Such notional values could also
be useful for other purposes besides dates.
The need for conversions to other calendars such as the Muslim, Jewish,
Hindu, Buddhist, Chinese and Japanese would be normal in those countries
to which they apply, though the SQL standard does not provide such
facilities. It may be that the appropriate authorities in the countries
involved would rather be wholly responsible for their application, but a
consistent approach for international communications may have advantages,
especially for Muslim countries. However, I now understand that not all
Muslim countries use identical reckoning. Julian dates could also be
considered, i.e. those of the Julian calendar. Special data-types for
dates represented by these other calendars may be appropriate. As well as
Julian dates, which are an obvious exception, not all these calendars use
the same method of reckoning for the number of days in a year and seconds
in a day.
The handling of dates, times and durations by SQL does not seem to
exactly reflect ISO 8601, calendar months are added to dates as calendar
months, not as 30 days, though to be fair, ISO 8601 does not set out to
prescribe date arithmetic rules or how systems should represent data
internally.
1.12 Adopting SQL date handling routines for COBOL, etc.
For COBOL and probably most other programming languages there is much to
be said for directly incorporating the date facilities of ANSI SQL. I
think that the simplest way would be to use the same procedural syntax as
that of the full SQL standard. Using identical syntax would make amending
a program to use an SQL based relational database much easier and would
reduce the likelihood of a program using more than one way of handling
dates. It would also help ensure that the SQL standard was more rigorously
applied by implementors. To allow manipulation of host variables without a
table access, ORACLE allows the provision of a dummy table-name, other
possible options include removing the need to specify a FROM clause in the
SELECT statement and using a pseudo table-name such as DATE or TIME, which
being reserved words could not be used as normal table-names anyway. There
is an argument for changing the SQL standard itself to accommodate this
idea, since the ability to manipulate dates independently of table
accesses can be useful within programs using an SQL based relational
database, as has already been recognised by ORACLE. I don't think it would
be an excessive burden on implementors that don't also supply an SQL based
relational database to supply such a facility within COBOL. Those
suppliers that do provide relational databases could still provide the
standalone facility for those users and programs that do not use a
relational database. The other programming languages within which SQL can
be used could adopt a similar approach, as could others that don't
currently implement SQL.
Changes required to COBOL and SQL for implementation:
a) It would be desirable to introduce DATE, TIME and TIMESTAMP
data-types into COBOL, so that host variables could be used efficiently,
other similar relevant datatypes could also be added. INTERVAL data-types
would be desirable, as might years and days with decimal places and
periods of time and durations as defined by ISO 8601. Corresponding
changes to the rules for embedded SQL would also be required to enable the
type of the host variable to be recognised so that appropriate conversions
would only be made when necessary. Such data-types could be regarded as
akin to the internal numeric formats, so COBOL operations on display data
would not be applicable, except on containing group items with similar
caveats.
Consider adding CALENDAR as a component of date and timestamp, to allow
different calendars to be used. Also perhaps A.D. and B.C., or the use of
negative and zero year numbers for dates earlier than A.D. 1 and similar
relationships in other calendars.
Consider adding one or two accuracy fields to timestamps, e.g. the
current UTC accuracy indicator and perhaps another to deal with
relativistic effects. The current UTC accuracy indicator might be called
UTC-ACCURACY. Note that there is a separate discussion on the effects of
possible delays in the application of a timestamp from the time that it
was obtained.
A review of SQLSTATE codes would be required, not only to identify
errors, but also difficult or ambiguous cases arising from conversions
using fields with inadequate precision, leap year and second anomalies,
etc.
b) It would be necessary to allow SQL statements to perform certain
operations, particularly date arithmetic, on host variables without
reference to tables.
c) Extensions to timestamp arithmetic - see notes below. To allow
durations to be expressed entirely as years or days or seconds
with optional decimal places. Also to permit conversions between the
different forms, with warnings where the precision of the sending operands
is not good enough to produce an accurate result for a conversion to the
level of precision of the destination fields. Watch out for leap
years and seconds. This can be done with the INTERVAL data-types,
except that years and days can not have decimal places at present.
One could make a strong argument for recommending that durations are
best specified with a start and end date and time to avoid ambiguities
arising from the application of leap years, variable month lengths and
leap seconds. The only other unambiguous representation of a duration is
as an interval of SI seconds with no other units.
d) TIMESTAMP values that are chronologically equivalent should be
regarded as equal. For example "1990-02-23-00.000000" and "1990-02-22-24.00.000000".
Alternatively, the second form should be disallowed.
e) Possible introduction of additional forms of NULL values to be called
NULL_LOW and NULL_HIGH, which would have all normal attributes of a NULL
value, except when involved in an ordering operation, when they would
respectively sort below and above all other values. Such forms would
satisfy normal tests for NULLs, but could also be tested for independently
as NULL_LOW and NULL_HIGH. I believe that other people are considering
alternatives to the current use of NULL to represent information that is
never relevant to a particular item and that which is merely currently
unknown.
f) SQL must define how leap years and seconds are to be handled and must
do so in a "future proof" manner that can be amended to
accommodate longer term and sudden changes in relationships. SQL and ISO
8601 should be consistent with each other.
This would have to bear in mind that leap seconds are applied
empirically when appropriate, so that some calculations involving future
dates of more than six months or a year in advance would be suspect and
should probably return a non-zero SQLSTATE value in the "01xxx"
group. Individual SQL systems could contain indications of how far in
advance leap seconds have been applied, they would be reset each time the
system was updated to account for an additional leap second, which is
normally known several months in advance.
g) As a not directly related improvement, I thing that a serial number
data type could be an asset, this would be of variable length to make
their representation infinitely expandable. Their manipulation could be a
subject for a specific type of object class, subroutine or function.
h) As far as possible, the new facilities should be backwards compatible
with existing standards and programs and have an easily applied upgrade
path.
i) Maintenance of the date handling facilities would then be the remit
of the ANSI SQL standards committee and ISO TC154, with appropriate
reference to the standards committees of the programming languages that
adopt it, any other relevant ISO standards committee and any other
relevant standards body.
Organisations using COBOL and other languages could write their own set
of standard user-defined intrinsic functions to provide additional date
handling facilities where needed. For example to identify tax periods,
accounting periods, working days, bank holidays, etc. Maybe this would be
better done by national subcommittees, where appropriate.
Another possible approach for COBOL could be to define an intrinsic
function to provide the date manipulation facilities of SQL with its
standard syntax, it could be called SQLDATE or DATESQL. Such a function
would need to be able to detect and report a variety of error conditions,
such as invalid data and dubious results, such as the 31st February. One
of its mandatory parameters would have to be for error handling. I don't
think that this approach is as good, though I should reconsider it. Such
an approach would then have to be duplicated for every programming
language that uses SQL.
Currently, the 1992 SQL standard leaves to implementors the question of
leap seconds, additional leap years or non-leap years and conversions and
manipulations of dates earlier than that of the Gregorian calendar. There
are in fact three levels of SQL standard, which have varying level of date
handling sophistication, IBM's DB2 version 3 seems to use level two.
1.13 Practical aspects of implementing a date/time subroutine
The use of SQL can be regarded as equivalent to using a subroutine.
To be able to calculate durations as the difference between two dates or
to calculate one date from another using a duration, the dates (and
eventually times) of leap seconds must be obtained dynamically and stored
in an expandable table. In the long term this table will become enormous
and the processing overheads significant, so consideration could be given
to defining multiple reference dates at which known equivalences are
specified. This may not be necessary yet, but subroutine design should
make it practical to implement when required. The date on which leap
seconds are to be applied is made public several months in advance and
could be transmitted along with the other regular time signals in advance
by the institutions responsible for the national clocks. I believe that
currently they are only published in technical journals and web sites for
the users to apply manually. Leap seconds are applied after the last
normal second of the day, at present usually on the last day of July or
December. Durations comprising a composite of units including
seconds would contain 60 seconds per minute, though I am minded to insist
that durations including seconds as units should be debarred and that such
durations should be maintained as a pure count of seconds.
The benefit of providing warning of leap seconds in advance with time
signals is that even though most equipment may have a permanent radio link
to obtain time signals and hence could make the adjustment at the exact
time, there may be situations where the radio is temporarily
non-functional, but with the advance notification the leap second could be
applied automatically anyway. A similar argument could also be made for
transmitting the date of the previous leap second, in case it was missed.
If it isn't always done already, it would be possible to regularly
transmit the current date and time. Also consider possible situations
where the equipment is being used in an application for which the
disruption of applying the leap second would be undesirable at the time
when it is due. On the other hand, such applications may use TAI for which
the problem of leap seconds doesn't apply.
In the very much longer term, similar considerations will also apply to
leap years, which will eventually be one day short of 365 days and even
less than that in the even longer term.
It could be desirable to provide a facility for applications to debar
setting or retrieving a time field during a leap second, while the
computer itself continues to operate normally.
The concept of triangulation as adopted by the European Union for
currency cornversions could be advisable, i.e. all conversions between
differing date and time formats to be done with one or more standard
intermediates, such as Julian days and TAI seconds. Comparison of
durations could be approached similarly. While it would be desirable to
provide standard conversions for Julian days and TAI seconds back to 4713
B.C., this would require assessing all the leap seconds required during
the period and I don't think that astronomical records currently provide
the necessary detail. I am not even sure that it is possible to go back to
A.D. 1582 with absolute confidence.
1.14 Potential changes to ISO 8601, Representation of dates and
times in information interchange
These notes are based upon the 1997 version of the draft revision.
It seems to me that it would be desirable to state that the Gregorian
calendar is a reasonable approximation, probably good for another 2000
years, but that in time it will need adjustment. Assuming current rates of
change in year and day length, the year 4000 probably should not be a leap
year. I think that the first introduction date for this calendar should be
stated, together with its relationship to the Julian calendar, which it
superceded, and references to a document listing the dates upon which
individual countries adopted it.
I think that the standard should state the purpose of the calendar
explicitly, which is to provide an administratively convenient mechanism
for the specification of points of time, specific periods of time and
durations in general. It is used to coordinate the measurement of tropical
years, mean solar days and SI seconds. As there is no long term fixed
relationship between these units, the calendar must necessarily be
periodically adjusted to adapt to circumstances and be designed to
accomodate such changes with the minimum of difficulty. This will require
the addition or subtraction of leap days and seconds. Ultimately, it can
be expected that years will contain less than 365 days and minutes will
contain more than 60 seconds.
I think that the treatment of leap years and leap seconds should be
logically consistent with each other. One refers to both leap years and
leap days, so why not leap minutes and leap seconds. I think that it is
desirable for the standard to be designed to be open ended with a view to
accomodating the most likely and even rather improbable, yet possible,
long term changes in relationship between tropical years, mean solar days
and SI seconds.
Conceptually, I think it is probable that years will always contain
twelve months and days will always be divided into 24 hours, in turn
always divided into sixty minutes. A statement of intent to this effect
might be desirable. So might a statement that calendar years and days will
always be equated with average tropical years and mean solar days, while
admitting the possibility of the long term need for coexisting calendars
for separate purposes such as space travel and settlement on other
planets. (Strictly speaking, calendar years are correlated with tropical
years by the use of leap days, such that calendar years always have a
integer number of days. Consequently individual calendar and tropical
years do not exactly correspond.) Statements of intent need not be
inflexibly binding, but would indicate long term plans that have
considered potential future requirements.
The standard could also consider the representation of sidereal time and
its relationship to the administrative calendar. Sidereal time is required
for navigation and related activities. It can be expected to eventually
become commonly available on items such as portable computers and
wristwatches, as well as more specialist equipment. My knowledge of the
definition, representation and use of sidereal time is very limited, so
further investigation would be required.
The 1st January 2000 is a Saturday, not a Wednesday.
The reference to "Rec ITU-R TF.460-4" should be revised to
reflect that the current version is now "Rec ITU-R TF.460-5".
The definition of a minute should reflect the fact that it may contain
less or more than 60 seconds.
Allow representation of dates as Julian Days and Modified Julian Days.
Provide an appropriate format for these representations and allow them to
be optionally associated with time. The base dates for these
representations should be stated and also state that 1st January 4713 B.C.
is a Julian date, rather than a Gregorian date.
Allow representation of dates and times, both separately and jointly, as
a pure number of seconds. Though this could be inferred from the reference
to ISO 31-1, it would be better if it were stated explicitly. Provide an
appropriate format for this representation. Also review the means by which
accuracy is represented. I would prefer a logarithmic scale, which would
be more adaptable to space travel and future improvements in timekeeping
accuracy. Perhaps two accuracy scales might be appropriate, one for
intrinsic accuracy and the other for relativistic effects.
Consider allowing representation of dates using only units of years,
days and seconds.
Consider representing the time scale for which a date and time is
represented, e.g. UTC, TAI, UT1, etc. Three digit alphabetic codes would
seem to be a reasonable mechanism, coordination of nomenclature with the
IAU would be required. This coding could be optional, but its placement
and format when present would need to be defined. Also consider allowing
representation of DUT1, etc. as attached fields in specified formats.
Specify the base dates or epochs applicable to UTC, TAI, UT1, TDB, TDT,
etc, for representations of counts of pure seconds. Dates earlier than the
base dates would be represented by negative values. The base points would
be represented as a zero value.
Note that while UTC and TAI use SI seconds as the standard duration
unit, other time scales may have seconds of slightly different lengths and
also be variable in length. Also that SI seconds are themselves subject to
small variations that are probably indefinitely acceptable for
administrative purposes.
Consider a mechanism for representing the calendar for which a date is
expressed, e.g Gregorian, Julian, Hebrew, Muslim, Hindu, Buddhist,
Chinese, Japanese, Julian day, Modified Julian day, UTC seconds, etc. This
could be an optional feature, where Gregorian is assumed unless stated
otherwise. I think that a code containing a minimum of three letters would
be advisable, along the lines of the ISO standard for the abbreviated
representation of countries' names and with codes distinct from those used
to represent any country. As well as the Julian calendar, which is an
obvious exception, not all calendars in current use have the same method
of reckoning for the number of days in a year and seconds in a day. Also,
I believe that the Muslim calendar, together with certain others, is not
necessarily consistent between countries or sects, so some further
categorisation may also be required. I now tend to think that it would be
unreasonable to include the Muslim calendar and that it would probably be
desirable for the standard to restrict itself to the Gregorian calendar as
adopted for use with UTC, together with the Julian calendar, Julian days,
Modified Julian days, UT1 and TAI.
It might be desirable to provide a consistent approach for use of the
terms A.D. and B.C. such that both either precede or follow a date,
probably without the normal full-stops that are formally correct in
abbreviations. It would be formally desirable to specify their optional
position within the standard date formats. Alternatively, define a
mechanism for using negative and zero year numbers. It is quite
conceivable that future scientific advances will make it possible to
specify the dates and times of historical events with greatly improved
accuracy.
1.14.1 Durations in ISO 8601
I have put this in its own subsection, as my comments are substantial.
It is a very tricky topic and has to steer an acceptable course between
established custom and practice and the need for accuracy in differing
circumstances.
(I am having a considerable struggle with it myself.)
For this discussion of ISO 8601: "period of time" is a term
used to describe a time interval associated with an end or start date or
both; "duration" is a term used to describe a time interval not
specifically associated with any start or end date.
I would personally prefer the use of the terms "relative duration"
and "specific duration" as being more self-explanatory, but this
is semantics.
I think it should be preferred practice to express a period of time
using both start and end dates and times, rather than using a duration
associated with a start or end date and time. I think that it would be
desirable for the standard to state this. My reasoning is that it is
reduces the risk of such durations being used out of context, when can
they become ambiguous, depending on the use to which they are put, which
may not be known at the time they are derived. Expressing periods of time
in this manner can also reduce the amount of calculations needed in
computer systems, since the start and end dates and times are often
sufficient in themselves for the processing that is required.
The primary mechanism for representation of a period of time
incorporating a duration allows for for the conventional treatment of leap
years, variable length months and leap seconds. I think that the standard
should explicitly state the convential treatment of durations, i.e. the
individual units of a duration are added to or subtracted from the
equivalent units in the start or end date, with carry over to the next
higher unit. Using this method, leap years, variable length months and
leap seconds are automatically incorporated, but with the handicap that
such a duration is not directly comparable with another associated with
different start and end dates.
I think that the standard should explicitly state that where a period of
time is expressed using a duration in the primary format, its duration is
not directly comparable with that of another period of time, unless both
durations are first converted to the equivalents in seconds. However, it
should also state that for administrative purposes, a number of calendar
years, months or days may be directly comparable, despite being strictly
unequal due to the differing number of leap days, days in a month or leap
seconds.
I think perhaps that the standard should explicitly state that a
duration expressed in the alternative format is directly reducible to a
specific number of seconds by simple arithmetic. Also to emphasise that
years expressed in this format have 360 days.
I think that the standard should specify the facility to specify
durations solely as a number of SI seconds, whether or not they are
associated with a specific start or end date. Though this could be
inferred from the reference to ISO 31-1, it would be better if it were
stated explicitly and a standard representation provided.
Where seconds are significant, it would be good practice for
durations that are to be compared with each other to be derived as a
number of seconds first. The 1992 SQL standard has a useful approach,
suitable for most administrative requirements, though its handling of time
intervals does not adequately deal with leap seconds, being implementor
dependent. Perhaps SQL time intervals should not allow seconds, which
would then be dealt with as a third form of interval data-type. - does
this belong here ?
For the expression of durations, there is something to be said for being
able to use the type of representation available in ANSI SQL (1992), where
the leftmost item may have an indefinitely large value, e.g. 1000 hours
and 20 minutes, expressed in extended format as T-1000H:20,0M. The
alternative format where the date/time components are only positionally
identified would not be permissible for this type of use, because of the
potential ambiguities. I also think that the standard should recommend
caution in the use of decimal places for any unit other than seconds,
because of the potential ambiguities that may arise from variations in
year, month and day length, both in the short and long term.
Consider introducing a duration type consisting of years, days and
seconds. This would still be subject to problems of ambiguity.
Date Arithmetic, with months, the usual treatment seems to be that
where an invalid date such as 30th February is calculated, it is
automatically reduced to the next lowest valid value, which might be 29th
or 28th February as appropriate. This could reasonably be regarded as long
established normal standard custom and practice, though at times other
treatments are appropriate. - does this belong here ?
While ISO 8601 does not currently prescribe practices for date
arithmetic, I think that it should consider accomodating the
representations needed to perform it. In particular, a normal period of
time implicitly includes leap years and leap seconds.
It is desirable to consult the industry, governmental bodies and other
standards organisations to determine preferred practices with respect to
the handling of durations.
1.15 Potential changes to Rec. ITU-R TF.460-5, Standard-frequency
and time signal emissions and related standards
I have only seen Rec. ITU-R TF.460-5, so these notes are somewhat
hypothetical.
For fields expressing specific dates and times, the format of the field
should be of variable length to accommodate an ever increasing number of
digits. If an upper limit on the scale of the field must be used, then I
think that it should accomodate an upper limit for the projected time from
the beginning to the end of the "big bang" event in the visible
universe.
The time signal radio frequencies should be multiplexed such that other
information relevant to calendars and time management can also be
transmitted. This could include the propagation of the level of accuracy
of the time signals being transmitted, the current date and time in UTC,
calendar updates, internationally available public holiday notification
for individual countries using a country coding scheme, the current
difference in seconds between TAI and UTC, other time measurements such as
TDT and TDB. I understand that DUT1 is already transmitted. Such
multiplexing would best be done in such a way as to allow existing
equipment and practices to continue to be used without interruption or
alteration.
An alternate mechanism for indicating the accuracy of UTC, etc. that
would use a logarithmic scale, to better accomodate future technical
improvements and time dilation due to relativistic effects as may be
required for space travel. Perhaps this could coexist with the existing
mechanism, such that the existing one would be used for intrinsic accuracy
including transmission delays and gravitational effects, while the other
would be used to deal with relativistic effects.
1.16 Desirable practices and pitfalls
Apart from the need for standards to be applied in the production of
facilities for use in date and time manipulations, there is also a need
for guidance on how they should be used.
There are three basic forms of duration in administrative timekeeping.
They are calendar years approximating to average tropical years, calendar
days approximating to mean solar days and SI seconds. These each have
their own uses and validity. Mixing them is problematic because of leap
years and seconds. The gradually changing relationships between them also
create further potential long term problems.
Durations are only completely unambiguous for the purposes of comparison
when they are associated with a base date as specified in ISO 8601 or
recorded as a number of UTC seconds. However, comparisons between whole
numbers of years or days are valid for administrative purposes. A minute
is a fixed, though not quite always equal, subdivision of a day, while a
second is not.
I have discussed the benefits of using start and end dates and times to
specify durations elsewhere.
When comparing timestamps to determine the duration between dates
without taking account of the time component, it is necessary to first
extract the dates before making the comparison. For most administrative
purposes, this eliminates problems with time discrepancies, as it is
usually only relevant whether or not a transaction occurred on a
particular day, or how many whole days have elapsed since the previous
transaction.
For many administrative transactions requiring higher precision,
accuracy to the nearest minute would usually suffice and again extraction
of this level of detail from a timestamp before making comparisons would
eliminate potential problems with leap seconds. ????
There are 31,556,952 seconds in a year of the Gregorian calendar, where
such years are on average 365.2425 days. At present, there is about one
leap second per year, but by A.D. 2100 there will be about two per year
and about sixty per year by A.D. 10,000. In a system that does not account
for leap seconds, the chance of a leap second causing a date discrepancy
in a duration of a single year is reduced by the number of seconds in a
day, i.e. about 86400. A further reduction of the chance is also obtained
by the relative unlikelihood of transactions occurring around midnight,
though the increase in international activity tends to negate this.
Although the chances of discrepancies having significant effects are very
small, they have to be weighed against the total numbers of transactions
that occur. The combined population of North America and Western Europe is
probably approaching 1000 million and there are significant other
economically important groupings with relatively high computer use, with
many more expected to become significant. If 1000 million people are each
involved in a single computer transaction every week, it can be seen that
a significant number of leap second related timing errors may occur to
affect transaction dating and reckoning. For durations exceeding a year,
the potential likelihood of discrepancies increase.
For most administrative functions and many others, the problem of leap
seconds is probably best handled by computer applications not doing any
work involving timer requests during them. To achieve this it is probably
best for computers to keep UTC time properly and for timer requests to be
handled by a subroutine with a switch to allow or disallow the retrieval
or setting of a time during a leap second.
Unless specifically necessary for an application, interacting computers
and systems should not depend on each other keeping or having kept the
correct time. The interface procedures should resolve any differences
where they matter. If a common time reference is needed it should probably
be arranged as a network time and ideally, but not necessarily,
synchronised with UTC. It may be the case that a single multitasking
computer could participate in several networks with differing time bases.
While it can be expected that all computers will regularly get UTC time at
intervals of about a minute as a matter of course in the future, it can
still be the case that UTC time may be temporarily unavailable to one or
several computers in a network for any of several reasons. It can also be
the case that not all such computers need or can be connected to a network
fulltime.
Potential delays in servicing requests as a consequence of multi-tasking
on general purpose computers with most modern types of operating system. A
special system of event and interrupt driven priorities might alleviate
this to a certain extent.
1.17 Not trying to do too much too soon
One could go further and define programming languages and systems where
there is no upper limit on the representation of date values because all
fields are defined as variable in length. The PICK operating system is
such a system. Even with such systems, there would still be a residual
problem in handling date literals, though one could perhaps then
reasonably assume that, where the year component of a literal was shorter
than the year field in the variable to which it was being compared, then
the missing preceding digits could be assumed to be zero.
This may be undesirable at present, because of the long term vagaries of
the relationships between years, days and seconds. It may be unlikely that
any standard in the near future would provide facilities to accommodate
all the problems discussed, in which case it may be unwise to plan to
perpetuate such an inadequate standard indefinitely, unless it restricted
itself to recording TAI and UTC seconds and decimal multiples thereof. It
would also be unwise to base very long term calendar revisions on rates of
change derived from records that have been kept for such a short time
relative to the period involved.
Fixed length fields are required for the practical display of dates on
screens and reports. This problem may be easier to circumvent in the long
term by advancing developments making it easier to vary font sizes
dynamically according to the number of significant digits present.
However, I do think that a standard that makes it relatively easy to
apply future changes as needed would be desirable. This also makes it
important to assess the nature of the future changes that will be
necessary eventually.
As it is a common practice to use four digits to record years, it would
be reasonable to try to plan to ensure that the hardware and software to
implement the calendar presently in use will work properly until the year
10,000, while bearing in mind that the uncertainties of future rates of
change in year and day length may make further adhoc adjustments
necessary. In practice, it is likely that a leap year should be omitted
from A.D. 4000, though even that is a good way off, but the then necessary
revision of calendar hardware and software would still benefit from having
years with a minimum of four digits, when pre-existing records will still
be valid.
There is some argument for always developing computer systems that are
good for the next factor of ten years, e.g. A.D. 10,000, A.D. 100,000,
etc. Such events would force a reevaluation and adjustment of all existing
software and hardware some years beforehand, maybe centuries ahead as time
progresses.
In some cases, it may only be possible to point out the pitfalls
awaiting the unwary and provide recommended practices for particular types
of circumstance. As may be apparent, I could probably do with some myself.
1.18 Legal aspects
Consumer law, criminal negligence and other legislation may drive some
aspects of development; for example, it might be said in a few years time,
that a computer without certain standards of operation is unfit for the
purpose for which it is intended, much as could be said for many computers
and software packages sold before the year 2000. Conformity with ISO and
national standards may not be an acceptable defence, if legally based
reasonable expectations are higher.
It could be beneficial for hardware and software producers to cooperate
in the development of a suitable standard in advance of the strict need,
this would reduce the impact of rigorous standards of expectations being
imposed retrospectively on existing hardware and software.
There may be a need for a legal view of time definition for cases where
times recorded from different systems may differ by as much as several
minutes, yet with no certainty that the earliest recorded was really
first. Perhaps each case should just be judged on its particular
circumstances.
In some circumstances, there might be potential hazards associated with
computers all operating at a synchronised clock frequency or various
harmonics of a particular frequency. This might lead to some rules being
necessary along the lines of soldiers breaking step when crossing bridges.
1.19 Glossary
More comprehensive explanations and details can be found in the
references; particularly the Astronomical Almanac and its explanatory
supplement, Kaye and Laby, Parise, Richards, Cheney, Encyclopaedia
Britannica, Encyclopaedia Americana, Jerrard & McNeill and good
dictionaries, from which, collectively, most of these descriptions have
been scrounged. There are also many good websites including that of the
NPL. I have provided exact figures for the definitions of lengths of
years, lunar months, days and seconds, but various up to date values can
be looked up in the above publications or their equivalents and various
web sites, of which some are listed. All measures of rotation rates and
angles vary in both short and long term periodic cycles and are also
subject to other short and long term changes. I recommend the IERS, NPL
and NAO as the best primary sources, though for a brief initial review,
Kaye & Laby's presentation is compact and fairly comprehensive, while
that of the Encylopaedia Britannica is rather more extensive. The above
publications have good sets of further references, as has the NPL website.
There have been several changes to the notations for expressing time in
the twentieth century, which can be quite confusing, especially since the
reference sources tend not to entirely agree with each other. GMT is a
term that is supposed to have been superceded, but is still used to refer
to both Coordinated Universal Time (UTC) and Universal Time (UT) when the
latter is used to refer to UT1, which is unfortunate, because they are not
equivalent, though both are logical successors to the original GMT and
have a defined relationship. Furthermore the term Universal Time is
variously used to refer to both UT1 and UTC. There are some more time
scales in the pipeline to replace or augment TDB and TT, the latter of
which was called TDT.
Julian date is a term that is frequently misused to refer to the use of
ordinal day numbers within years without the use of month numbers, known
as ordinal dates. It is also often confused with the use of Julian days,
particularly unfortunate, since the definition of Julian days is founded
upon the proleptic use of the Julian calendar to define day zero.
When dealing with historical dates and those of other calendars, it is
necessary to be sure of the calendar used, how long the years were,
whether they varied in length, the months used, whether the days recorded
started at midnight, noon, sunrise, sunset, or some other astronomical
event, how days were counted, when new year's day was, when leap days were
applied, the use of daylight saving time, the time zone and the exact
relationship with the Gregorian calendar. Many historical dates are
reckoned by reference to specific events, particularly regnal terms and
religious festivals. Several methods of dating often coexisted for various
aspects and purposes. Cheney, Richards and Parise are most helpful.
While abbreviations formally contain intervening periods, they are
commonly omitted, especially in standards documents.
A.D. - Anno Domini (in the year of our lord) - the term used in
the Gregorian and Julian calendars to denote years including and since
A.D. 1. It is formally correct for the term to precede the ordinal number
of the year, as shown. However, when associated with a descriptive century
representation it follows that description, e.g. fourth century A.D. It is
a tautology to use the expression "the year A.D. 1". It is
acceptable to use the form "1 A.D." and the periods are
sometimes omitted. In the western world, dates not qualified with either
A.D. or B.C. are generally assumed to be A.D. The terms "year of
grace" and "Christian era" can instead be used with an
ordinal year number to indicate the years since 1 B.C.
altitude - 1) usually height above or below sea level. 2) the
angular distance in a plane at right angles from the plane of the horizon
of the observer to an object, it is analogous to latitude, cf. azimuth.
antarctic circle - the circle parallel to the equator south of
which there are days on which the sun does not set. The latitude is about
66.5 degrees.
aphelion - the point furthest from the sun in the orbit of a
planet or other body orbiting the sun, cf. perihelion.
apogee - the point furthest from the Earth in the orbit of the
Moon or other satellite, cf. perigee.
arctic circle - the circle parallel to the equator north of
which there are days on which the sun does not set. The latitude is about
66.5 degrees.
azimuth - the angular distance in an east to west plane from the
north to south plane of the observer to an object. It is analogous to
longitude, cf. altitude.
B.C. - Before Christ - the term used in the Gregorian and Julian
calendars to denote years prior to A.D. 1. There was no year 0. It is
formally correct for the term to follow the ordinal number of the year,
e.g. 46 B.C. While the expression "the year 46 B.C" can be used
and is grammatically correct, it is acceptable to just use "46 B.C".
Sometimes the periods are omitted. Astronomers use zero and negative
values for dates before A.D. 1, so 1 B.C. is 0, 2 B.C. is -1, etc.
B.P. - Before Present, a term commonly used by archaelogists and
geologists to refer to a date as a number of years before the present
date. Such dates are by their nature approximations and are usually of the
order of several thousand years ago or more, so the slight ambiguity of
expression arising from the specification of the reference base date is
not usually important.
calendar - an administratively useful relationship between
tropical years, mean solar days and SI seconds. This is the meaning
generally understood here, but there are others that also relate lunar
months. The Egyptians and Babylonians knew 4000 years ago that the length
of the tropical year was about 365.25 days. The administrative or civil
calendar is usually designed to keep step with the seasons, which is why
it is usually based upon the average tropical year and mean solar day.
calendar, civil - the administrative calendar regulated by a
government for use in civil affairs. Internationally, most countries now
use a calendar based upon a defined relationship with UTC and the
ecclesiastical Gregorian calendar.
calendar, Gregorian - a calendar introduced by Pope Gregory XIII
of the Roman Catholic church in A.D. 1582 to correct the inaccuracy of the
Julian calendar. It retained the main relationship between years and days,
but added the rule that years whose ordinal number was divisible by 100,
but not 400 were not to be leap years. This calendar bases the
relationship between calendar days and years on there being 365.2425 mean
solar days per tropical year. The reform also confirmed new year's day as
the 1st of January and that days start at midnight. It made no difference
to the day of the year on which leap years were applied, which at that
time was the day after the 23rd February and called the 24th February,
when ordinal day numbers were used. The means by which Easter Sunday was
to be calculated was revised at the same time. The new calendar was first
introduced on the 4th October 1582, which was immediately succeeded by the
15th October, thereby omitting 10 days from the record. However, it wasn't
adopted immediately by all Christian countries, the United Kingdom adopted
it on the 2nd September 1752, which was immediately succeeded by the 14th
September 1752, thereby omitting eleven days. England also adopted new
year's day as the first of January for 1752. As a consequence, those days
that would have had the dates 1st January 1751 to 24th March 1751 were
instead in 1752. Also, the English legal year of 1751 contained 281 days,
while that of 1752 contained 354 days. In several places, Christmas day
was then observed on 5th January 1753, which was 365 days after the
previous Christmas, and some continued to do so until the late nineteenth
century. Other countries adopted the Gregorian calendar at various dates
up until the early 20th century. The Gregorian calendar is also known as
the "new style calendar".
calendar, Julian - a calendar, introduced by Julius Caesar in 45
B.C. on the advice of Sosigenes, an Alexandrian scholar, that adopted a
calendar year of 365 mean solar days, except that in each fourth year a
leap day was to be added. Consequently, 67 days were added to the year 45
B.C. such that the beginning of March became the first of January and the
beginning of the new year. For thirty six years, the leap days were
applied every three years by mistake, but this flaw was then corrected by
omitting intercalary days between 10 B.C. and A.D. 3. A.D. 4 was the next
leap year, though of course at that time it would have had the Roman year
numbering. The twelve months in common use were regularised by this
calendar, though a minor adjustment involving the naming and the length of
the month of August and the lengths of some other months was made by the
emperor Augustus, who succeeded Julius Caesar. The leap days were applied
after the sixth day before the kalends of March to become the second sixth
day before the kalends of March, or as most would understand it after the
23rd February to become the 24th February. The kalends of March was the
1st March and the Romans used inclusive counting. Leap days were
officially designated as the 24th February in the United Kingdom until
1662. The changeover from the Roman practice of reckoning days in advance
of the kalends, nones and ides of a month to the present use of a single
series of ordinal day numbers for a month gradually occurred during the
middle ages up until the nineteenth century in certain papal documents.
Originally, this calendar counted years from the date when Rome was
considered to have been founded in 753 B.C., using the somewhat unreliable
reckoning of the previous Roman republican calendar. But in Rome, in A.D.
532, Dionysius Exiguus (Denis the little), introduced reckoning from the
supposed date of the birth of Christ in 1 B.C, then only for the purposes
of compiling a table for calculating the date of Easter. It wasn't until
the eighth century that this new year numbering was adopted as a general
way of designating years, after its promotion by the Venerable Bede of
Jarrow. This convention was officially adopted in England by the Council
of Chelsea in A.D. 802. However, it still wasn't universally adopted
within Western Europe until the eleventh century. Later research indicates
that Christ was probably born several years earlier than 1 B.C., though
the exact date of his birth is still unknown. The official introduction of
the seven day week was made by the emperor Constantine in the fourth
century A.D. The Christian year numbering has been adopted by ISO 8601.
This calendar bases the relationship between calendar days and years on
there being 365.25 mean solar days per tropical year. Astronomers still
make use of the Julian year. While the Roman Catholic church permanently
retained the first of January as the first day of the solar year, for
various periods other countries did not, including England and later the
United Kingdom. Both the Romans and the Papacy also used other systems of
reckoning year numbers and other days to start the administrative year at
various times, as did most other countries and organisations. The British
Parliament still refers to statutes with regnal year numbers as well as
the year of grace. The Julian calendar is also known as the "old
style calendar".
calendar, Julian proleptic - the dating system employing the
rules of the Julian calendar for application to and derivation of dates
prior to the introduction of the Julian calendar. It was used in
determining the start date for Julian days.
calendar, new style - see Gregorian calendar
calendar, old style - see Julian calendar
calendar, perpetual - a scheme for indicating the day of the
week for any date within several or more particular years.
century - a one hundred year relative or specific duration,
usually used to refer to 100 years of the current civil calendar. Also
used to refer to all years in a calendar with the same ordinal century
number. When using a term such as the fourth century A.D., this is
understood to comprise all years commencing with a three for the ordinal
century number, i.e 300-399. This applies for both A.D. and B.C. dates.
While that may seem odd, the reasoning is that the first century A.D.
comprises the years A.D. 1 to A.D. 99., a short century of 99 years, since
there was no year designated A.D. 0, nor for that matter a year designated
0 B.C.
century, Julian - 100 years as defined by the Julian calendar
and equal to 36525 mean solar days. The relevant specification of the
length of a mean solar day should be included when the term Julian century
is used.
COM - I think this is Microsoft's alternative to CORBA.
concurrents - see dominical letter
Coordinated Universal Time - see UTC
CORBA - Common Object Request Broker Architecture - a standard
object oriented architecture providing common interfaces and descriptions
for objects.
date - a particular calendar day of a particular calendar year,
usually represented as a specific day of a specific month of a specific
year, or as a specific month containing a specific day for a specific
year. ISO 8601 prescribes the representation of dates to be of the forms
YYYY-MM-YY and YYYY-DDD.
date arithmetic - the calculation of new dates and times from
other dates and times by using addititive and subtractive durations. Also
the calculation of durations between specific start and end dates and
times. A very tricky topic, the rules of which vary according to
circumstances. SQL seems to have tackled the subject quite effectively,
especially the IBM version in DB2 version 4 and ORACLE 7. The SQL standard
itself seems somewhat vague in some respects. ISO 8601 does not deal with
this topic, except to mention it with respect to the variable number of
days in a month.
date, integer - used as a synonym for ordinal date
date, Julian - this is a date reckoned by the Julian calendar,
the format is the same as the Gregorian calendar. The term Julian date is
frequently misused to refer to the use of ordinal dates and is frequently
confused with Julian Day.
date, line - an imaginary line on the Earth's surface for the
purpose of fixing the change of date, without ambiguity, for all
travellers. It generally corresponds with 180 degrees longitude, but
deviates around certain island groups for local convenience. When the date
line is crossed from west to east, the reckoning of the local date
advances by one day and vice versa.
date, ordinal - this is a date that reckons calendar days within
calendar years without the use of month numbers, the ordinal numbers of
the days range from 1-365 for ordinary years and 1-366 for leap years.
day - generally, the time that it takes a planet to rotate on
its axis, though it is also used to denote the duration between sunrise
and sunset. In this context it is used as an equivalent to the time that
it takes the Earth to rotate on its axis. Used without further
qualification, it is usually understood to mean calendar day. Individual
days normally commence and end at midnight, but see GMT and Julian day.
day, calendar - is related to the mean solar day almost exactly,
leap seconds are used to maintain this relationship, but are only inserted
about once a year at present, so there is a slight discrepancy between the
length of days with and without a leap second. Administratively, all
calendar days are normally regarded as being of equal length.
day, Julian and Modified Julian - a Julian day is a reckoning of
mean solar days from noon on 1st January 4713 B.C., when day 0.00 started.
The Julian date, 1st January 4713 B.C. is also known as the start of the
Julian period. A modified Julian day is calculated as a Julian day minus
2,400,000.5 days and starts at midnight. Julian days were devised by
Joseph Scaliger and named in honour of his father in 1583. The backward
extrapolation from A.D. 1582 to 4713 B.C. is done using the Julian and not
the Gregorian calendar. Year 0 does not exist, 1 A.D. is immediately
preceded by 1 B.C. However, astronomers when using Julian days, do have a
year zero and don't use the terms A.D. and B.C., so by their reckoning
Julian days start from the year -4712. Originally, the count of Julian
days was based on a Julian cycle of 7980 years, after which the day
numbers would repeat, but now it seems probable that the count will just
be maintained indefinitely.
day, leap - this is a calendar day inserted after the 28th
February in leap years to become the 29th February. It is expected that
fewer will be required in the medium long term, since the length of the
tropical year is gradually shortening and the length of the mean solar day
is increasing.
Also known as a intercalary day. The opposite of intercalary is
extracalary. Cycles of extracalary days will eventually be necessary with
the reduction in the ratio of the length of mean solar days to the length
of the tropical year.
day, mean solar - the average time that it takes the Earth to
complete one rotation on its axis, measured as the time between two
successive transits of the Sun. The actual duration of a day as measured
in SI seconds can vary by up to 50 seconds through the year. Its length in
about 1984 was 86400.003 SI seconds and has been increasing at the average
rate of about 17 milliseconds per millennium, during available historical
records from about 153 B.C. The calculated rate of increase based upon
calculation of the Moon's tidal effect is about 23 milliseconds per
millennium, but this is not applicable in the short term, because of the
effects on the Earth's weight distribution of the most recent ice age. The
rate of increase during historical records has varied from about 14 to 20
milliseconds per millennium.
day, new year's - the calendar day on which a calendar year
commences. While the Julian calendar originally used the first of January,
which was permanently retained by the Roman Catholic church for the start
of the solar year and for determining the ecclesiastical calendar, various
other countries and the eastern Orthodox church did not, for various
periods. The Roman Catholic church also used various other days as the
start of the new year for administrative purposes. England conformed on
the 1st January 1753 as part of the calendar reform adopting the Gregorian
calendar. It had been Lady day, the 25th of March, from A.D. 1338 in
England, when it had been the 25th of December from the seventh century
A.D., when year reckoning was nearly a whole year behind. Scotland made
the change in 1600. In several countries, the reckoning of new year's day
varied between different organisations, especially near the dates of
changeovers. Considering the various different rules, it would not be
surprising if some dates were inadvertently misrepresented by the authors
of surviving documents.
day, quarter - these are days marking the four quarters of the
year as used administratively in England, Scotland and the United States.
Their dates are thought to have originated with the dates of certain
Celtic festivals.
In England, they are Lady Day on the 25th March, Midsummer on the 24th
June, Michaelmas on the 29th September and Christmas on the 25th December.
In Scotland, they are Candlemas on the 2nd February, Whitsuntide on the
5th May, Lammas on the 1st August and Martinmas on the 11th November. In
the United States, they were rationalised as the first days of January,
April, July and October.
day, sidereal - the average time that it takes the Earth to
complete one rotation on its axis, measured as the time between two
successive transits of a star. It is about four minutes shorter than the
mean solar day. It is less than the mean solar day, because of the Earth's
movement while orbiting the Sun. It is also very slightly less than the
Earth's rotation period with reference to an inertial time frame. Its
length in about 1984 was 86164.094 SI seconds.
daylight saving time - the regular setting of clocks ahead of
the local timezone's mean solar time, to provide more daylight in the
evening. It is often called summer time, since it is usually applied
during the summer and adjacent months.
decade - a ten year relative or specific duration. Also used to
refer to all years in a calendar with the same ordinal decade number.
declination - the angular distance of the celestial sphere
measured north or south from the celestial equator. Can be thought of as
analogous to latitude, cf. right ascension.
dominical letter - the letters A to G are used in correspondence
with the ordinal numbers 1 - 7 according to the date on which the first
Sunday of a year falls, e.g. a year with the first Sunday on the 4th
January would have D as the dominical letter. In leap years, the dominical
letter is reduced by one for the period after the leap day. Concurrents
are very similar but have ordinal numbers and don't change within leap
years. Dominical letters and concurrents are used to calculate Easter.
duration - a length of time
duration, addititive and subtractive - relative durations used
for the purpose of deriving new dates and times from others. These often
consist of partial sets of date and time units, e.g months. See date
arithmetic.
duration, relative - a duration not associated with any
particular date and time. Care must be taken to ensure that the
representation of a duration is not ambiguous due to leap days, variable
length months and leap seconds. The easiest way to represent a duration
unambiguously is as a record of SI seconds. However, a record of either or
both years and days may be appropriate in some situations. ISO 8601 and
ANSI SQL differ on the representation of such durations, neither being
entirely satisfactory, but then it is a difficult subject. Relative
durations often consist of partial sets of date and time units.
duration, specific - the particular duration between two
specified dates and times or both. For example, where the recording of a
duration is in whole days, then, depending upon the circumstances, the
associated time need not be specified.
DUT1 - the predicted value of the difference between UT1 and
UTC. It is transmitted with broadcast time signals.
Easter - this Christian religious festival is based upon the
relationship of lunar phases to the vernal equinox at Jerusalem, though it
uses a notional average synodic month and the vernal equinox is assumed to
always be on the 21st March. The appropriateness of its timing will
eventually be affected by the current slight discrepancies and long term
changes in the relationships of the mean solar day, average tropical year
and average synodic month. At least some of the churches are considering
making it a relatively fixed date within the calendar year, presumably,
since it must be on a Sunday, something along the lines of the first or
second Sunday in April. Neither the Vatican nor the Anglicans have an
objection in principle to such a change. While most Christian groups use
the method prescribed by the Gregorian calendar reform, the Eastern
Orthodox Church never adopted this reform and, after using the Julian
calendar until 1923, it made its own separate calendar reform. Several
other religious festivals of various faiths also depend upon the synodic
month.
According to the Dionysian canon, Easter is on the first Sunday that
follows the paschal full moon. The paschal full moon is defined as the
first notional full moon on or after the notional vernal equinox on 21st
March. The notional full moon is governed by relatively simple rules and
the prediction of the date of its phases does not depend upon observation
or elaborate astronomical calculations.
E.G. Richards' book "Mapping Time" contains useful formulae
and algorithms for calculating Easter, they are also available from his
web site.
ecliptic - the apparent path of the Sun relative to the stars,
the mean intersection plane of the Earth's solar orbit and the celestial
sphere. Also see celestial equator.
epact - the age of the moon, the number of days since new moon.
The epact of a year is the age of the notional moon on the first day of
the year. The concept of epacts is used in calculating the date of Easter
Sunday.
ephemerides - plural of ephemeris.
ephemeris - a tabulation of the positions of a celestial object
in an orderly sequence for a number of dates.
epoch - an arbitrary fixed instant of time or date used as a
chronological reference point for calendars, celestial reference systems,
orbital motions and star catalogues. The epoch of most calendars is the
first day of the first year of that calendar, but not necessarily when
that calendar was first introduced.
epoch, standard - from 1984, the new standard epoch of the
fundamental astronomical coordinate system is J2000.0 and is the calendar
date 2000 January 1.5d, which is the Julian day JD 2,451,545.0. It is used
as the basis for the measurement of ephemerides. The unit of time in the
fundamental formulae for precession (and in similar expressions) is the
Julian century of 36,525 days of 86400 SI seconds (the tropical century is
not to be used).
equator - the great circle around the Earth's surface formed by
the intersection of a plane through the Earth's centre, perpendicular to
its axis of rotation. Also known as the terrestrial equator. A mean value
is normally used.
equator, celestial - a great circle on the celestial sphere in
the same plane as the Earth's equator. A mean value is normally used. It
is currently at an angle of about 23.5 degrees from the ecliptic.
equinox - either of two points on the celestial sphere at which
the ecliptic intersects the celestial equator. Also either of two times
during a year when the Sun crosses the celestial equator. At these times,
the length of day and night are approximately equal throughout the world.
The vernal equinox, also known as the first point of Aries, occurs in the
spring around about the 21st March. The autumnal equinox, also known as
the first point of Libra, occurs in the autumn around about the 23rd
September. While in Babylonian times the first point of Aries lay in the
constellation of Aries, the precession of the equinoxes has resulted in it
now being in Pisces and it will soon be in Aquarius. Similarly, the first
point of Libra is now in Virgo and will soon be in Leo. Cf. solstice.
era - a system of chronological notation reckoned from a given
date.
gematria - the assignment of numeric values to letters of the
alphabet and using them to derive numeric values for letter groupings.
glacial rebound - see isostasy, the opposite effect (glacial
depression!) would presumably be significant during a period of extensive
glaciation.
GLONASS - Global Orbital Navigation Satellite System, the
Russian satellite navigation system, which provides time as one of its
services and does not have the Selective Availability feature of GPS,
thereby allowing it to provide a higher level of accuracy for generally
available time.
GMT - Greenwich Mean Time, a term now superceded by UTC. Though
most people still refer to UTC as GMT (including the BBC and its shipping
forecasts), some others refer to UT1 as GMT. It was internationally
adopted in October 1884, with the meridian of the transit instrument at
the Royal Observatory, Greenwich being adopted as the prime or zero
meridian. This led to the adoption of 24 standard time zones. Originally,
until 1925, days started at noon and, as a consequence of the confusion
ensuing from the change, in 1928 the International Astronomical Union
(IAU) adopted the term Universal Time (UT) instead. The time and frequency
broadcasts of the United Kingdom and the United States were synchronised
in 1960 and scheme expanded in 1964 under the IAU into a worldwide system
called Coordinated Universal Time (UTC). When GMT days were reckoned from
noon to noon, they were twelve hours ahead of the local administrative
day.
GMST - Greenwich Mean Sidereal time.
Golden Number - the number of a year within a metonic cycle. It
is normally expressed in Roman numerals and ranges from I - XIX. It is
used in the calculation of Easter.
GPS - Global Positioning System. This system has 24 satellites
primarily intended to provide a facility to enable people with suitable
receivers to identify their exact location. It is operated by the US
Government primarily for military use, but with a deliberately degraded
capacity (Selective Availability) for civilian applications for which it
is nevertheless very useful. Each satellite contains several coordinated
atomic clocks with which to maintain GPS time, which is closely related to
TAI and uses a system of week numbering which is recycled from 0-1023. UTC
can be obtained from it by knowing the number of leap seconds by which UTC
differs from TAI. Also see GLONASS.
GPSDO - Global Positioning System Disciplined Oscillator
GSD - Greenwich Sidereal Date, the number of sidereal days
elapsed at Greenwich since the beginning of the sidereal day that was in
progress on Julian day 0.0.
hour - a duration of 60 minutes, there are 24 in a day. Also a
specific hour of the day, identified by its ordinal number, which varies
from 0 to 24. The only use for the hour number of 24 is to denote midnight
at the end of the current day, the minute and second values associated
with this particular hour number always being zero. The original
definition of an hour was as 1/12th of the actual day and similarly as
1/12 of the night, so the lengths varied according to the seasons. When
reasonably accurate clocks became available, it was later revised to mean
24 equal subdivisions of the mean solar day. In normal everyday use, hours
are reckoned in numbers from 1 to 12, where those of the morning are
suffixed a.m. and those after noon are suffixed p.m. Reckoning using the
24 hour clock was introduced for railways and navigation and is much more
common now, most commercial computer systems now use it.
hour circle - a great circle on the celestial sphere that passes
through the celestial poles and is therefore perpendicular to the
celestial equator.
Indiction - a cycle of fifteen years numbered from one to
fifteen. The cycles were always computed from A.D. 312. It is calculated
by subtracting 312 from the year of grace, dividing the result by fifteen
and adding one. Usually, only the year in the indiction is specified in
documents and not also the number of the indiction. The start of a year of
an indiction was not usually the same as the start of a year of grace.
isostasy - the tendency of the Earth's crust to have equal
weight distribution. It can be upset by glacial deposition and melting,
though then tends to recover over a longer period.
longitude - the arc of the equator between the meridian through
the point and the meridian at Greenwich. It is generally measured in units
of 0 to 180 degrees east or west of Greenwich, where 180 degrees east or
west are equivalent longitudes and are jointly the other half of the great
circle constituting the Greenwich meridian.
lunar phase - cyclical apparent forms of the moon, e.g. new
moon, first quarter, full moon, and last quarter.
lunation - the duration between two consecutive new moons.
meridian - a specific longitude, the prime meridian is longitude
zero, which is also known as the Greenwich meridian. It can also be
described as half of any great circle the plane of which intersects the
Earth's poles.
Metonic cycle - a duration of 19 years, used in various
calendars as it very nearly contains a whole number of average lunar
months.
midnight - twelve o'clock at night, in the 24 hour system it may
be represented as 24.00 hours at the end of the day or as 00.00 hours at
the commencement of the following day.
millennium - a one thousand year relative or specific duration,
usually used to refer to 1000 years of the current civil calendar. Also
used to refer to all years in a calendar with the same ordinal millennium
number. Commonly also used to refer to the year or exact time at which a
specific millennium starts or ends with various minor variations, e.g.
1999, 2000 and 2001.
minute - a duration of 60 seconds, there are 60 in an hour. Also
a specific minute of the hour, identified by its ordinal number, which
varies from 0 to 59. The original definition of a minute was as 1/1440th
of a mean solar day, or 1/60th of an hour defined as 1/24 of a mean solar
day.
minute, leap - conceptually similar to the term leap year, a
minute containing a additional leap second.
month - a unit of time with a relative duration of between 28
and 31 days. Also a specific month of a year identified by its ordinal
number. Usually used as a synonym for calendar month, but may also refer
to synodic or sidereal lunar months.
month, calendar - a unit of time resulting from the division of
a calendar year into twelve sequential periods of time, each with a
specific name and containing a specified number of days. In the Gregorian
and Julian calendars, the months of the year, listed in their order of
occurrence, are named and contain the number of days as follows: January
(31), February (28 in common years, 29 in leap years), March (31), April
(30), May (31), June (30), July (31), August (31), September (30), October
(31), November (30), December (31). It can also be used as a unit of time,
but is rather unsatisfactory because of the potential ambiguity of
meaning. Administratively, a calendar year is often considered to contain
twelve equal calendar months, the intended meaning depending on the
circumstances.
month, lunar - usually a synodic month, the durations of its
several forms vary periodically and are gradually changing over the long
term.
month, sidereal - the duration of the Moon's orbit around the
Earth using fixed stars as the reference points, its average length is
just over 27.25 days. Its average length is 27.321661 days of 86400 SI
seconds.
month, solar - one twelfth of a tropical year.
month, synodic - the duration between repeated phases of the
Moon (e.g. new or full moon), its average length is 29.53059 days of 86400
SI seconds and is longer than the duration of a single orbit, because of
the Earth's own motion. Over the long term its duration is gradually
increasing and in the short term its length can vary by as much as several
hours from one lunation to another.
month, tropical - the duration of the Moon's orbit around the
Earth using the equinoxes as the reference points. It is very slightly
less than the sidereal month. Its average length is 27.321582 days of
86400 SI seconds.
nadir - the point directly below an observer, cf zenith.
noon - twelve o'clock in the middle of the day. In local time it
corresponds to the Sun's highest point in the sky during the day, but in
practice because of the application of timezones and daylight saving time
this event does not usually exactly correspond with local clock time. In
GMT, until 1925, this was the start of each day.
NPL Truetime - an NPL service that allows a computer to set its
clock to within one fiftieth of a second by direct telephone connection to
the national time scale at the NPL.
nutation - the short-period oscillations in the motion of the
pole of rotation of a freely rotating body that is experiencing torque
from external gravitational forces. Used to describe the oscillation of
the Earth's poles about the mean position, it has a period of about a
nineteen years.
obliquity - usually the angle between the celestial equator and
the ecliptic. Currently about 23.5 degrees and subject to slight
oscillations. It is thought by some to perhaps have exceeded 54 degrees,
at which point the Earth's poles receive more sunlight than the
terrestrial equator, allowing glaciation to occur there rather than the
poles. The lunar orbit is about 5 degrees from the ecliptic. At present,
the Earth's mean obliquity is slowly increasing as a consequence of tidal
interactions with the Moon, while that of the Moon is gradually
decreasing.
OQL - Object Query Language, the potential successor to SQL,
from which it is derived.
orbit - the path and speed of a satellite around its parent
body. Orbits are invariably elliptical and not truly circular, nor even
truly elliptical, so the speed varies with the distance from the
barycentre. The closer a satellite is to its parent body, the faster it
must travel to provide the angular momentum to offset gravity.
Gravitational acceleration provides the impetus. Satellites are perturbed
by other satellites, other planets and their sun. Measurements of orbit
that are based upon phenomena such as the rotation speed of the object
being orbited and time between successive apogees, aphelions, or like
equinoxes may vary separately and may separately increase or decrease in
duration. While all orbits eventually decay because space is not a
vacuum and planets, etc aren't truly rigid, tidal effects and
perturbations from other objects, including solar winds, meteors and
comets, can have opposite influences. I am now dubious about including
this, since I have been unable to find confirmation of the inevitability
of orbital decay. At present tidal evolution reducing the Sun's rotation
rate is much more significant, acts with the opposite effect and will
outlast our ability to survive on Earth, since it will only cease when the
Sun itself stops rotating, which will only happen long after it becomes a
red giant engulfing at least some of the inner planets. The Moon's orbit
around the Earth is also currently expanding due to tidal effects and this
will continue until the Earth's rotation slows to maintain the same face
towards the Moon, again probably after the Sun becomes a red giant.
perigee - the point nearest the Earth in the orbit of the Moon
or other satellite, cf. apogee.
perihelion - the point nearest the sun in the orbit of a planet
or other satellite, cf. aphelion.
precession - an effect shown by a rotating body when a torque is
applied in such a way as to tend to change the direction of its axis of
rotation. See nutation.
precession of the equinoxes - the Earth's axis of rotation
slowly precesses around the pole of the ecliptic, causing a slow drift of
the equinox with respect to the stars. So the mean length of the sidereal
day is slightly shorter than the period of rotation with respect to an
inertial time frame. Also, the westward motion of the equinoxes caused
mainly by the attraction of the Sun and Moon on the equatorial bulge of
the Earth. The equinoxes thus make one complete revolution of the ecliptic
in 25,800 years and the Earth's pole turns in a small circle of radius 23
degrees and 27 minutes about the pole of the ecliptic, thus changing the
relative coordinates of the stars.
proleptic - applied to the use of a calendar to specify dates
before its inception or epoch.
right ascension - the angular distance of the celestial sphere
measured eastward along the celestial equator from the vernal equinox to
the hour circle passing through the celestial object. Can be thought of as
analogous to longitude, cf. declination.
second - a duration that is normally a sixtieth part of a
minute. Also a specific second of the minute, identified by its ordinal
number, which normally varies from 0 to 59, but may be 60 in a leap
minute. The original definition of a second was as 1/86400th of a mean
solar day, or as 1/60th of a minute defined as 1/60th of an hour defined
as 1/24 of a mean solar day. However, it was later found that the mean
solar day gradually increases, so that the relationship between calendar
days and clock seconds was not static. Consequently, the SI second was
introduced as being of fixed length and leap seconds are added to or
subtracted from calendar days when required.
The SI second is the basic unit of measurement of time in the
International System of units (SI) as defined in ISO 31-1.
second, ephemeris - a now superceded unit, see ephemeris time.
However, it is still valid historically.
second, leap - a second that is added at the end of a minute to
compensate for the discrepany between the mean solar day and exactly 86400
SI seconds. One is usually added every year at the end of December or
June, it is expected that the frequency of their application will increase
in the long term, as the length of the mean solar day is gradually
increasing. Notice of additional leap seconds is published by the IERS
several months in advance of their application.
second, SI - the fundamental unit of time as defined by the
General Conference of Weights and Measures (CGPM) in 1967 and adopted by
the International Standards Organisation (ISO) and the International
Astronomical Union (IAU). It is defined as the the duration of
9,192,631,770 cycles of radiation corresponding to the transition between
two hyperfine levels of the ground state of cesium 133, at sea level and
unperturbed by external forces. There are slight periodic variations (see
TAI). It would appear that the method of definition was chosen as a
trade-off between accuracy and the need for a practical method of
providing an instantaneously available scale, rather than having to wait
several years. There are developments in progress by the NPL and others to
improve the resolution and reduce the variability.
sidereal - generally of the stars and constellations. Used here
in the context of measurements made using stars and galaxies as reference
points.
solstice - there are two of these, the summer and winter
solstices, at which the Sun is at its highest and lowest points
respectively in the sky. They occur around the 21st December and 21st June
respectively, cf. equinox.
sphere, celestial - an imaginary sphere of infinite extent with
the Earth at its centre.
SQL - Structured Query Language - a user programming language
for relational databases originally developed by IBM and now adopted by
the ISO. It is the increasingly commonly accepted method of handling
relational databases.
summer time - see daylight saving time
TAI - International Atomic Time, this is the fundamental
reference timescale, intended to provide both an invariant unit of time
(the SI second) and an unambiguous, precise method of identifying any
instant of time. However, it is not convenient for general use, for which
UTC is designed and maintained in a close relationship. The arbitrary
epoch is 1st January 1958, chosen such that UT1 and TAI were coincident.
TAI was introduced on 1972 January 1, when the difference between TAI and
UTC was made exactly 10 seconds. Atomic time scales have been kept since
1956, so by the use of special corrections, TAI can be extrapolated back
to that date. From 1962 an increasing number of international time signals
were coordinated to provide a consistent time standard and were
synchronised with the redefined UTC in 1972. In 1984, the estimate of the
uniformity of the scale was 1*10**-13, so the accumulated error in epoch
was less than one nanosecond per year. It should be noted that TAI does
have some slight variations due to gravitational perturbations mainly
arising from the ellipticity of the Earth's orbit. As with other methods
of measuring time, it is liable to be affected by relativistic effects.
tide - the effect of the gravitational attraction of the Moon
and, to a lesser extent, the Sun, on the waters of the Earth, by which
they tend to become heaped up at the point below the Moon, and at the
opposite point to this, so that twice in each lunar day there is an
alternate inflow and outflow on the coasts. The solid crust, mantle and
core is similarly affected, though to a much lesser extent. The tides
cause variations in the rate of the Earth's rotation.
tidal evolution - the effect of tidal distortions on the
semi-rigid bodies of the Earth and Moon, this results in a gradual
diminution of the rate of rotation until one face of each body permanently
faces the other. The Moon's orbit expands correspondingly with the
decrease in the Earth's rotation, consequently the speed of the Moon in
its orbit decreases, so the time taken to complete an orbit increases.
Tidal evolution also applies to other orbiting bodies, though the effects
are more complex when more than two bodies are involved. Tidal evolution
also tends to reduce the eccentricity of an orbit and can have yet other
effects.
time - a nonspatial continuum in which events occur in
apparently irreversible succession from past through present to future.
Any specific or relative point or duration on this continuum. Although
this definition includes the use of dates and is correct, "Time"
is also used to represent time of day using hours, minutes and seconds.
While the subject is open to considerable philosophical debate, in
practical terms it is measurable in unvarying units, so far as anyone can
determine physically.
time, dynamical - descriptively, the independent variable, T, in
the differential equations of motions of celestial bodies. There is a
family of dynamical time scales, introduced in 1984 to replace ephemeris
time, including Barycentric Dynamical Time (TDB) and Terrestrial Dynamical
Time (TDT). Terrestrial Dynamical Time is now called Terrestrial Time
(TT). They are independent of the Earth's rate of rotation and orbit and
differ from each other only by regular periodic cycles. TDB is arguably
the most consistent form of time reckoning, with no variations in the
length of its units being detectable at present. There are moves in the
pipeline to replace or augment these scales.
time, ephemeris - time derived from the Earth's orbital motion.
Descriptively, the independent variable, T, of the differential equations
for the motions of the Sun, Moon and planets under the influence of their
mutual gravitational attractions. It has been superceded by dynamical time
for current purposes in which it is necessary to take account of
relativistic effects, but is still valid for historical purposes.
time, local - (1) the clock time in public use locally. The
difference between local time and UTC time is determined by the national,
regional or local authority responsible. The difference depends upon the
time zone and may also be varied during the course of a year, normally as
a consequence of the regular application of daylight saving time. This is
the meaning used administratively.
(2) the time of day appropriate to the longitude of the location to
which it applies according to the determination of the local mean solar
day. This meaning is relevant to navigation and related activities.
time, mean solar - time based upon the mean solar day.
time, rotational - time measured using the rate of the Earth's
rotation as the basis, some of the several forms are subject to
adjustments to smooth out short term variations in solar day length. See
Universal Time (UT).
time, sidereal - time based upon the axial and orbital motions
of the Earth with relation to the stars. Local sidereal time refers to
that of the longitude of the location to which it applies. This is
important for navigation and related activities. See "day, sidereal",
"year, sidereal" and "Greenwich mean sidereal time (GMST)".
time signal - the regular transmission of UTC by radio,
telephone or other means. Several countries maintain UTC and provide
regular time signals that also include DUT1, so that UT1 can be
calculated. TAI can be calculated from UTC by knowing the number of leap
seconds applied since UTC and TAI were coordinated. The IERS web site
contains this information. The signals are maintained within +/-2 *
10**-12 of the nominal frequency and corrections to the radiated
frequencies are subsequently published to +/-1 * 10**-13.
time, solar - time based upon the Sun's apparent motion through
the skies. The time indicated by a simple sundial is known as local
apparent time or local solar time and it differs from local mean solar
time by the "equation of time", the effects are dependent on the
seasons. The difference ranges between about -14 minutes and +16 minutes
during the year. The main causes of the differences arise from the
eccentricity of the Earth's orbit and from the inclination of the plane of
the Earth's orbit to the plane of the Earth's equator.
timestamp - a term used in SQL to denote a combined date and
time recording, with or without a timezone.
timezone - an administratively convenient subdivision of
longitude extending an average of 15 degrees from pole to pole, throughout
which the same clock time is generally used. The global system of
timezones allows local clock times to reasonably approximate to local mean
solar times for the benefit of social convenience, while also providing an
easily calculable relationship to UTC. Most countries adopt timezones that
differ from UTC by an integral number of hours, but a few use half hour
differences or local time. Timezones east of the Greenwich timezone have
clock times in advance of UTC, while timezones to the west have clock
times in arrears of UTC.
tropic - there are two of these, the tropic of Cancer and the
tropic of Capricorn, in the north and south hemispheres respectively. They
are the two circles parallel to the Earth's equator that mark the furthest
points north and south at which the Sun can be directly overhead at noon.
The term "the tropics" usually refers to all the latidudes
between these two circles. The latitudes of these circles are about 23.5
degrees north and south. The Sun reaches these circles at the equinoxes
and the full cycle of the period between successive repetitions is called
the tropical year. Because the Earth doesn't move at constant speed in its
elliptical orbit, the seasons are not of equal length, with the effect
that, in the northern hemisphere, spring and summer are longer than autumn
and winter.
truetime - see NPL Truetime
week - this can be used either as a term for any period of seven
calendar days or for any specific period from a Monday to the following
Sunday. Religious weeks, also of seven days, may start on a Friday,
Saturday or Sunday and maybe some others days too. Administratively, weeks
are considered to be of equal length whether or not they contain a leap
second. In the Gregorian calendar, the first week of the year is that
which includes the 4th January. In ISO 8601 the first week of the year is
that which includes the first Thursday of that year. The first week of a
calendar year can contain days of the preceding year and the last week of
a calendar year can contain days of the following year. The week numbers
of a calendar year can be represented by the ordinal numbers 1-53, where
there may be 52 or 53 weeks in a calendar year. In ISO 8601, the first day
of the week is Monday. In the Gregorian calendar, the first day of the
week is Sunday.
UTC - Universal Coordinated Time, also called Coordinated
Universal Time, but the abbreviation is always UTC. It replaced GMT as the
standard time for the prime meridian. 32 leap seconds have been added
since 1st January 1958, when it was coincident with TAI. It is maintained
to within +/- 0.9 seconds of UT1 by the use of leap seconds and always
differs from TAI by an integral number of seconds. One second of UTC is
equal in duration to one second of TAI, i.e. an SI second. It is often
still referred to as GMT. See time signal.
UT - Universal Time, when it is used to refer to UT1, is
formally defined in terms of Greenwich mean sidereal time (GMST) by a
conventional expression that ensures continuity with past practice and yet
frees UT from irregularities that would arise from certain effects in
orbital motion of the Earth around the Sun. Even so, it does not provide a
uniform timescale due to variations in the Earth's rate of rotation. UT1
is the form of time required for navigation and related activities. The
notations UT0, UT1 and UT2 are now supposedly obsolete, but UTR has been
introduced recently to indicate that the values have been adjusted by
removing the effects of certain short-period tidal terms. Where UT
is used without further qualification, it is usually understood to refer
to UT1, but can also refer to UTC. IERS still uses UT1 and publishes DUT1
regularly. It is often still referred to as GMT. The explanations given by
the Astronomical Almanac and by Kaye and Laby are very good, if slightly
inconsistent.
UT0 - a UT scale determined directly from stellar observations,
this is dependent upon the place of observation.
UT1 - a UT scale that is independent of the location of
observation, derived from UT0 by removing the effect on the observer's
meridian due to the observed motion of the geographic pole.
UT2 - a UT scale derived from UT1 that has a standard correction
for the seasonal variations.
UTR - another UT scale that has had certain short term tidal
effects removed.
year - generally, the time that it takes a planet to orbit its
sun. In this context it is used with respect to the Earth's orbit around
the Sun, usually as an equivalent to calendar year.
year, anomalistic - the duration between successive passages of
the Earth through the perihelion.
year, astronomical - the duration in which the right ascension
of the mean Sun, i.e. the angle between the meridians of the Sun and the
vernal equinox, increases by 360 degrees. Also known as Bessel's year or
annus fictus.
year, calendar - a year defined by an administrative calendar.
In the Gregorian calendar, it is related to the tropical year by the rules
for the application of leap days, such that over the long term the average
tropical year closely matches the average calendar year. It normally
contains 365 days, leap years contain 366 days. Administratively, calendar
years are normally regarded as being of equal length. Year 0 does not
exist, 1 A.D. is immediately preceded by 1 B.C.
year, Gaussian - the theoretical time, calculated from Kepler's
laws, for the Earth to orbit the Sun.
year, Julian - derived from the Julian calendar instituted by
Julius Caesar, it has a duration of 365.25 mean solar days. It is used by
astronomers who do not use the Gregorian year for most of their
calculations, astronomers measure the days as being of 86400 SI seconds.
year, leap - a calendar year containing 366 days, one of which
is a leap day.
year, sidereal - the average time for the Earth to complete one
orbit of the Sun using fixed stars as the reference points, it is about 20
minutes longer than the tropical year. The length of the average sidereal
year will be 365.256,360 days of 86400 SI seconds on the first day of A.D.
2000. Its length is increasing at the rate of 0.000,000,1 days per Julian
century. It is slightly different from the actual length of the Earth's
orbit around the Sun, due to the Sun's own motion through the Milky Way
and the Milky Way's own motion through the Universe.
year, tax - in the United Kingdom, this is the period for which
the Inland Revenue calculates our annual taxes. It is the same length as
the calendar year, but it starts on the 6th April. It used to start on
Lady Day, the 25th March, but the English financial year was changed in
1753 to start on the 5th April after the adoption of the Gregorian
Calendar, in order to accomodate the eleven days that were omitted from
the record. It was changed again in 1800 to start on the 6th April. The
Inland Revenue also has its own system of tax weeks and months, which run
from the 6th April until the 5th April in the following year. Tax months
run from April to the following March and are numbered from one to twelve,
with April being month one. Tax weeks run from April 6th to the following
April 5th and are numbered from one to fifty two, though if a pay day is
on April 5th in an ordinary year or on April the 4th or 5th in a leap
year, then the tax week is 53, 54 or 56, respectively for weekly,
fortnightly and four-weekly paid employees. There are special rules
applicable to these additional tax weeks. As tax weeks start from the 6th
April, so the tax week applicable to a particular weekly payment depends
upon the calendar day of the calendar week that pay is due.
year, tropical - the average time between two successive
passages of the true Sun through the vernal equinox. This is the period
used as the basis for the definition of most calendars, including the
Gregorian calendar. It is the period that keeps pace with the seasons,
which is why it is used in preference to other ways of defining the length
of a calendar year. The length of the average tropical year will be
365.242,193 days of 86400 SI seconds on the first day of A.D. 2000 and was
365.242,199 days on the first day of A.D. 1900. Its length is decreasing
at the long term rate of 0.000,006 days per Julian century. Its length
also varies in periodic cycles.
zenith - the point directly above an observer, cf. nadir.
1.20 References
My name is Robert Jones and I live at The Basement Flat, 29 Midland
Road, Gloucester, GL1 4UH, United Kingdom. My email address is
100621.553@compuserve.com. I am able to provide this document in a variety
of formats, the best of which are WordPerfect 5.1, WordPerfect 7, HTML and
plain text. Though it can be done, I have found that conversion to
Microsoft Word 6/7 and RTF upsets the outline numbering and some of the
alignments, at least when viewed with the Microsoft Word 97 viewer.
These references are to publications that I consider relevant. They are
not all easily accessible to me and some may not even still survive, so I
have not been able to read or recheck all of them. Those from Nature tend
to be less directly relevant, but contain further references that may be.
1.20.1 Primary references
The Roman edict of Julius Caesar that introduced the Julian Calendar in
45 B.C. As the leap days were not originally implemented correctly, a
further adjustment had to be made within a few decades. (Julian dates are
dates reckoned with the Julian Calendar, they are not to be confused with
Julian days.) - unseen
The Roman edict of Constantine I that introduced the seven day week
into the Julian calendar in the fourth century A.D. - unseen
The Council of Chelsea in A.D. 802, when the use of the Christian era
was formalised, such that the date of Christ's Birth in 1 B.C. was used as
the base point for the reckoning of years. The basis for this had been
initiated earlier by Dionysius Exiguus in A.D. 532 in his extension of the
scheme for Easter calculations. Full acceptance in Western Europe was not
achieved until the eleventh century. - unseen
The papal bull of 1582 that introduced the Gregorian Calendar with
effect from the Julian date 4th October 1582, which was immediately
followed by the Gregorian date 15th October 1582, i.e. omitting ten days.
It was applied in several Roman Catholic countries, others following suit
at various later dates. - unseen
"Explicatio Romani calendarii a Gregorio XIII P.M. restituti",
by C. Clavius in Rome in 1603. Available on microfilm. Clavius' original
explanation of the Gregorian reform in Latin. It contains the compendium
of Lilio's proposal. - unseen
The United Kingdom act of parliament of 1751 (24 Geo. II, ch 23) and
called "An act for regulating the commencement of the year and for
correcting the calendar now in use" that adopted the Gregorian
Calendar with effect from the Julian date 2nd September 1752, which was
immediately followed by the Gregorian date 14th September 1752, i.e.
omitting eleven days. It applied to the British colonies, those that later
became independent retained the revised calendar. - unseen
Various state orders of other countries to adopt the Gregorian Calendar
at various dates from 1582 until the 1920's. Many countries still continue
to use other calendars, but most, if not all, use the Gregorian Calendar
for international business activities. - unseen
The UK Parliament's Easter Act of 1928, which allows an "Order of
Council" to fix the date of Easter as the first Sunday after the
second Saturday in April. It has never been used. - unseen
General Conference of Weights and Measures (CGPM) in 1967 - adopted the
current definition of the SI second. - unseen
The Supplement to the Astronomical Almanac provides a list of the dates
on which each country adopted the Gregorian calendar.
ISO 8601-1988, (BS7151-1989, then BS EN 28601-1992), Representation of
dates and times in information interchange. A revision is in progress,
which among other items will permit the representation of leap seconds.
ISO 31-0:1992, Quantities and Units - Part 0 - General Principles.
ISO 31-1:1992, Quantities and Units - Part 1 - Space and Time.
Rec. ITU-R TF.460-5, Standard-frequency and time signal emissions.
Rec. ITU-R TF.686, Glossary. - unseen
Article 33 (S26) of the Radio Regulations, published by ITU -
unseen
1.20.2 Relevant organisations
ACM (The Association for Computing Machinery) - www.acm.org
ANSI (American National Standards Institute)
BCS (British Computer Society) - www.bcs.org.uk
BIPM (International Bureau of Weights and Measures)
BSI (British Standards Institute) - www.bsi.org.uk -
email:info@bsi.org.uk
CGPM (General Conference of Weights and Measures)
IAU (International Astronomical Union)
IEC (International Electrotechnical Commission) - www.iec.ch
IEE (Institute of Electrical Engineers) - www.iee.org.uk
IEEE (Institute of Electrical and Electronic Engineers) - www.ieee.org
IERS (International Earth Rotation Service) -
http://hpiers.obspm.fr - email: iers@obspm.fr
I sent them an email in October 1998, but have not had a reply
IETF (Internet Engineering Task Force) - www.ietf.org
ISO (International Standards Organisation) - www.iso.ch
ISO programming standards wwwold.dkuug.dk/JTC1/SC22 - some, not all
WG11 Language Binding Committee - an ISO subcommittee for developing
computer language independent definitions and facilities -
www.wwwold.dkuug.dk/JTC1/SC22/WG11
ITU (International Telecommunications Union) - www.itu.int/publications
NAO (H.M. Nautical Almanac Office) - www.ast.cam.ac.uk/~nao/
- telephone: 01223-374000
NPL (National Physical Laboratory) - www.npl.co.uk (look up "Time
and Frequency" in the "Science" subject box), also
www.npl.co.uk/ctm/index.html
- email: enquiry@npl.co.uk
I sent him an email in September 1998 and he replied that he would be
too busy until the end of November and suggested that I ask the IERS. I
rang him on the 9th December and he thought the committee responsible for
BSI 7151 (ISO 8601) would be the best people to approach. He also said
that I would have to lobby hard.
NPL CTM (NPL Centre for Time Metrology)
UKAS (United Kingdom Accreditation Service)
WTO (World Trade Organisation)
1.20.3 Publications of standards organisations
WTO TBT (Technical Barriers to Trade) - Code of Good Practice for the
Preparation, Adoption and Application of Standards presented in Annex 3 to
the WTO's TBT agreement.
ISO/IEC JTC 1/SWG-GII (Joint Technical Committee 1/Special Working
Group - Global Information Infrastructure) - Roadmap: Guidelines for
Evolution, Management and Development of GII standards
X/Open specification for the implementation of UTC - unseen
BSI document: Disc PD2000-4 Guidance and Information on PD2000-1:1998,
apparently states that no system with a knowledge of dates can operate on
an infinite range of dates and every such system is therefore subject to
some ultimate date limitations. - extract from letter by Keith Taylor to
The Computer Bulletin of March 1999 - the BSI document is unseen by
me
ANSI COBOL 1997 draft
ANSI ADA 1983 and 1995
ANSI SQL 1992
The Astronomical Almanac 1999, published by the Nautical Almanac
Office, United States Naval Observatory on behalf of Congress and Her
Majesty's Nautical Almanac Office, Royal Greenwich Observatory on behalf
of the Particle Physics and Astronomy Research Council. Sections L, the
Explanation, and M, the glossary, are particularly helpful.
Explanatory supplement to the Astronomical Almanac, 1992. It contains a
list of all the dates on which the Gregorian calendar was adopted by
individual countries. - unseen
IERS Technical Note 21 - IERS Conventions (1996) by Dennis D. McCarthy
(ed.) - July 1996. Doesn't seem directly relevant, but it has lots of
references and may bear further re-reading when I know more.
Language Independent Datatypes - ISO11404:1996 - includes date/time
Standards for RDS/EON and related facilities - to be found
1.20.4 General reference sources
Encyclopaedia Britannica 1995 ed. (under Time not Calendar) - states
that year length in 1900 was 365.242196 days and that in 2000 it will be
365.242190 days, i.e. a decrease of 0.000006 days per century. The days
used are of 86400 SI seconds.
Encyclopaedia Britannica 1997 ed. (under Time not Geochronology) -
states that solar day increases secularly by about 1.6 milliseconds per
century, that the rate of the Earth's rotation decreases by about one part
in a million every 5000 years, and rotational time loses about 30 seconds
per century squared. (This looks like three ways of stating the same
thing - I should check their equivalence.) It states that the annual
seasonal term, nearly periodic, has a coefficient of about 25
milliseconds. It states that it is hard to distinguish the long term
changes from the shorter term periodic changes, one of which has not yet
completed its cycle since it began in about A.D. 1650. It states that
years divisible by 4000 should not be leap years until the year 20,000
when a further adjustment will be required. (I disagree with this last
item, because I don't think that it takes account of decreasing year
length or increasing day length. The derivation given is only correct for
the current day and year lengths.)
(1.6 milliseconds per century = (1.6/100*1000) = 0.00000016
seconds/year)
(1 part per million per 5000 years = (1/1,000,000*5000)*86400.033
= 0.00001728 seconds/year) ??????????????????
(30 seconds per century squared = (30/100*100)/365.242196 =
0.0000082 seconds/year) ????????????
Encyclopaedia Britannica 1997 ed. - states that a Julian day is a
reckoning of days from noon on 1st January 4713 B.C., when day 0.00
started. 1st January 4713 B.C. is also known as the start of the Julian
period. A modified Julian day is calculated as a Julian day minus
2,400,000.5 days and starts at midnight. A Julian period is 7980 years,
but is not now used, as the current intention seems to be to continue to
number days from the original start date. Julian days were devised by
Joseph Scaliger and named in honour of his father in 1583. A Julian year,
though, is a term derived from the Julian calendar instituted by Julius
Caesar and is 365.25 mean solar days. The backward extrapolation from A.D.
1582 to 4713 B.C. is done using the Julian and not the Gregorian calendar.
Year 0 does not exist, A.D. 1 is immediately preceded by 1 B.C.
Encyclopaedia Britannica 1997 ed. - states that, according to the coral
record, about 400 million years ago day length was about 22 hours and that
year length was about 400 days. (Presumably the hours were in current
units while the days were the mean solar days of the era.) Also see
Geochronology, which states that day length is increasing by about 20
milliseconds per century, in contrast to 16 milliseconds per century as
stated under Time. Also states that 400 million years ago the lunar cycle
was about 30.5 days.
Encyclopaedia Britannica 1997 ed. under Geochronology, the Cretaceous
Period (distinctive features) - states that "The Cretaceous was
magnetically quiet relative to the subsequent Tertiary Period. In fact,
magnetic reversals are not noted from the early Aptian to the late
Santonian, a period of some 34 million years. The Earth's synodic months
have changed regularly for at least the last 600 million years owing to
tidal friction and other forces that slow up the Earth's rotation. The
rate of change in the synodic month was minimal for most of the Cretaceous
but has accelerated since. The reasons for these two anomalies are not
well understood".
Encyclopaedia Britannica 1997 ed. under Pleistocene climate changes.
Discusses the effect of periodic variations in the Earth's orbit,
obliquity and precession.
Encyclopaedia Brittanica 1997 ed. under Celestial Mechanics, discusses
tidal evolution, etc.
Tables of Physical and Chemical Constants, 15th Ed., 1986,
Longman - G.W.C. Kaye and T.H. Laby - ISBN 0-582-46354-8
In particular, chapter 1.9 "Astronomy and Geophysics".
states that year length is 365.242193 days and that it is decreasing at
the rate of 0.0000061 days per century, where days are of 86400 SI
seconds. Specifies the mean solar day to be 86400.003 seconds in 1984.
States that mean value of solar day increases by about 20 milliseconds in
1000 years.
ditto - 16th Ed. 1995 @ 46, gives year length and rate of change as the
same. Also gives rate of decreasing day length as the same.
ditto - 16th Ed., mentions International Earth Rotation Service (IERS)
as the current body providing Earth data.
ditto - 15th Ed., states that "The unit of time in the fundamental
formulae for precession (and in similar expressions) is the Julian century
of 36,525 days (the tropical century is not to be used). The new standard
epoch is designated J2000.0 and is the calendar date 2000 January 1.5d,
which is the Julian day JD 2,451,545.0".
Handbook of Physical Quantities, edited by I.S. Grigoriev and E.Z.
Meilikhov, CRC Press 1997 @ 96. Gives year length as 3.15569259747 x
10**7. Also states that the tropical year contracts by 0.5305 seconds per
100 years, which is equivalent to 0.00000614 days per 100 years. It also
gives current day length as 86400.003 seconds.
Astrophysical Data: Planets and Stars by Kenneth R. Lang ,published by
Springer-Verlag in 1991. Has data on orbit and rotation. States that the
length of day increases by (2.00+/-0.2) milliseconds per century (Lanbeck
1980) or (2.40+/-0.04) milliseconds per century (Stephenson & Morrison
1984). States that long term non-tidal changes are -8 milliseconds between
A.D. 950 and the present (1991) and that the deceleration in rotation
since A.D. 950 is 2.7 x 10**23 radians per second.
Dictionary of Scientific Units, 6th ed. by H.G. Jerrard & D.B.
McNeill, published by Chapman & Hall in 1992.
Newnes Telecommunications Engineer's Pocket Book, 2nd ed. 1998,
especially pages 102-106, which discuss frequency standards and time
signals.
James Q. Jacobs gives tropical year as 365.24219878 - 6.14 x 10-6 (TE) days, where TE is the tropical century of 36525 days, presumably these are mean solar days of 86400 SI seconds exactly
at http://www.geocities.com/Athens/Olympus/4844/astrofor.html
GPS Overview at www.utexas.edu/depts/grg/gcraft/notes/gps/gps.html - by
Peter H. Dana of the Department of Geography at the University of Texas at
Austin - highly recommended by the NPL as an introduction to GPS.
United Kingdom, Inland Revenue - PAYE Tax Tables - Pay Adjustment
Tables, Tables A - 1993 issue.
United Kingdom, Inland Revenue - Employer's Further Guide to PAYE and
NICS (CWG2(1998))
1.20.5 Various publications in journals, etc
Computing, 17th September 1998, reported that there is a date problem
in the Global Positioning System that could upset some older receivers
when the 1024th week is reached on 21st August 1999.
Scientific American, Spring 1999, Volume 10, no 1, "New Satellites
for Personal Communications" by John V. Evans.
Nature, Vol 385, 27th February 1997, p801 - "Eccentricity forcing
of Pliocene-Early Pleistocene climate revealed in a marine oxygen-isotope
record" by Steven C. Clemens & Ralf Tiedemann. Mentions
Milankovitch theory and climate cycles of 23Kyr, 41Kyr, c100Kyr and
c404Kyr accounted for by variations in the Earth's orbital parameters.
There might be even longer cycles, but the available geological records do
not appear to be able to show them, or at least not yet. I may be wrong
about this and longer ones might already be known from other sources.
Nature, Vol 388, 24th July 1997, pp331-2 - "Earth Rocked by
Combination Punch" by Dieter Stoffler and Phillippe Claeys. Discusses
the Popigai. and Chesapeake Bay impact structures of about 35 million
years ago, these closely coincide with an extinction event around the
Eocene/Oligocene boundary.
Nature, Vol 388, 24th July 1997, pp365-368 - "The age of the
Popigai impact and its relation to events at the Eocene/Oligocene boundary",
by Richard Bottomley, Richard Grieve, Derek York & Victor Masaitis.
Nature, Vol 388, 7th August 1997, pp567-570 - "Orbitally paced
climate oscillations across the Oligocene/Miocene boundary", by James
C. Zachos, Benjamin P. Flower & Hilary Paul. Refers to orbital
variations, namely the Milankovitch periods of 19, 23, 40, 100 and ~413
kyr.
Nature, Vol 396, 3rd December 1998, pp405-406 - "An oblique view
of climate" by Bruce G. Bills. Discusses mechanisms by which tilt or
obliquity of the Earth's rotation could change. Gives some detail on long
term periodic effects.
Nature, Vol 396, 3rd December 1998, pp453-455 - "Low-latitude
glaciation and rapid changes in the Earth's obliquity explained by
obliquity-oblateness feedback" by Darren M. Williams, James F.
Kasting & Lawrence A. Frakes.
New Scientist, 30th January 1999, no 2171, pp 30-3 - "In the
Shadow of the Moon" by Marcus Chown. The use of eclipse records from
136 B.C. to determine the rate of change in the Earth's rotation. This
allowed the average rate of increase in day length to be calculated as 1.7
milliseconds per century. It also states that records indicate that the
rate ranges from 1.4 to 2.0 milliseconds per century. It explains that,
while calculations involving the Moon's tidal influence indicate that day
length should be increasing by 2.3 milliseconds per century, the effect of
the loss of ice from the last ice age and glacial rebound, which is still
continuing, results in the Earth being slimmer around the equator with the
effect of it spinning faster than would otherwise be the case. Eclipse
records are available from 700 B.C. but the article doesn't say whether
those earlier ones can be used similarly. The article also doesn't discuss
projected rates of change in day length during ice ages. From the
calculations involving the Moon's tidal influence and the reason given for
the discrepancy, I would presume that the values calculated using the
Moon's tidal influence would be the best for use with very long term
periods containing several ice ages. The article refers to Richard
Stephenson's book "Historical Eclipses and Earth's Rotation"
(Cambridge University Press).
New Scientist, 27th March 1999, vol 161 no 2179, central insert on Time
Measurement produced by the NPL, contains useful information and further
sources and events.
The Times on 18th November 1998, states that 50 tons a day of cometary
dust reaches Earth and that, during the Leonids, that could increase by a
factor of ten thousand. Presumably the same would apply to other meteor
showers.
The Times on 2nd February 1999, letter from John Chambers, a research
scientist at the Centre for Time Metrology, National Physical Laboratory
in England. States that there will be a problem on 31st August 2132, when
the Modified Julian Date will be 99999 and the next day will be recorded
as 00000.
Computer Shopper, issue 130, December 1998, Correspondence, page 895: a
response to a reader's letter about interrupts and real time systems, in
which Mike James writes that the DOD insisted that ADA didn't use
interrupts because they make a program non-deterministic and non-provable.
In answer to a subsequent letter of response, he backtracked a little, but
stuck by his sources and reasoning.
Computer Shopper, issue 134, April 1999, Microcontrollers feature, page
633; indicates that many embedded controllers of a much simpler nature
could not conceivably use time signals, etc.
1.20.6 Historical sources
Frank Parise ed., "The Book of Calendars", Facts on File Inc,
1982
Cheney C.R. "Handbook of Dates for Students of English History",
1995, E.G. Richards recommends it. Though intended for historians, it can
be of current relevance, for example, to scientists interested in using
eclipse data - I have only seen the 1981 edition.
Richards E.G., "Mapping Time - The Calendar and its History",
Oxford University Press, 1998. A good exposition with a lot of useful
references. Web site: www.zetnet.co.uk/egrichards/ : email:
egrichards@zetnet.co.uk - various errata in my directory \trial\egrich
Algorithm P on p 376 of "Mapping Time";
1. A <= Y/100
2. B <= A - A/4
3. C <= Mod(Y,19)
4. D <= Mod(15 + 19*C + B - (A - (A - 17)/25)/3,30)
5. E <= D - (C + 11*D)/319
6. S <= 22 + E + Mod(140004 - Y - Y/4 + B - E, 7)
Said to be valid until A.D. 100,000. By this date the intentions of the
Council of Nicea would have thwarted yet again. Beyond this date the
constant 140004 may be replaced by another of the form 4 + 7X where 7X GE
5*Ym/4 and Ym is the maximum year required.
I suspect that changes in the application of leap years will affect
this calculation long beforehand.
Duncan D. E. (1998) "Calendar: Humanity's Epic Struggle to
Determine a True and Accurate Year", Avon Books, New York @23USD
- unseen
"Historical Eclipses and Earth's Rotation" by Richard
Stephenson, Cambridge University Press. - unseen
Encyclopaedia Britannica 1997 ed. under CALENDAR and TIME.
1.20.7 Computer texts
IBM DB/2 version 4 (I have not seen version 5)
Bourdon R.J. "The Pick Operating System - A Practical Guide",
Addison-Wesley, 1987.
The CORBA Reference Guide by Alan Pope, published by Addison-Wesley in
1998 at 27.95. This includes a chapter on time, which seems to indicate
that CORBA manages to evade the problem of dates by not dealing with them.
However, it has a point, in that using a record of UTC seconds is a
reasonably easily manageable, unambiguous and accurate way of recording
dates and their intervals. That is not to say that managing times in
seconds securely doesn't have its problems, as the book explains. Time
recording in CORBA uses the UTC definition, which it explains. CORBA's
record of UTC seconds starts from 00.00.00 on 15th October 1582, at the
same time that the Gregorian calendar was first introduced. The CORBA
implementation will currently last until A.D. 30,000, planned changes to
CORBA involve using larger containing fields. It may be that OQL covers
the subject of dates, but I have not as yet found anything out about OQL,
which I believe is the successor to SQL and stands for Object Query
Language.
I think that this definition probably treats all days prior to the
redefinition of UTC in 1972 as containing 86400 seconds as per previous
standards. An epoch coincident with TAI might have been preferable, with
dates earlier than 1972 represented by negative values.
Delphi 2, for its date handling facilities. This uses a 64 bit field to
hold an day number commencing from 1st January 1899. The decimal portion
of this number is used to specify the hours, minutes and seconds. I
don't yet know how many decimal places are used.
SQL The Standard Handbook, by Stephen Cannan and Gerard Otten,
published by McGraw-Hill in 1993. This explains the 1992 SQL standard.
Chapter 24 contains a discussion on NULL values. The book also contains
explanations of date, time and interval representation and manipulation.
Codd E.F. (1986) "Missing information (applicable and
inapplicable) in relational databases", SIGMOD RECORD, 15(4),
December, 53-78. - unseen
Codd E.F. (1987) "More commentary on missing information in
relational databases (applicable and inapplicable)", SIGMOD RECORD,
16(1), March. - unseen
Kocharekar R. (1989) "Nulls in Relational Databases - Revisited",
SIGMOD RECORD, 18(1), March 68-73. - unseen
Sarda N.L. (1990) "Algebra and query language for a historical
data model", Computer Journal, 33(1), 11-18. - unseen
Snodgrass R. (1989) "Correspondence from R. Snodgrass",
SIGMOD Record, 18(3), September, 102-103. - unseen
Snodgrass R. and Ahn I. (1985) "A taxonomy of time in databases",
Proceedings of ACM SIGMOD International Conference of Management of Data,
May, Austin, Texas, ACM, New York. - unseen
IBM re synchrony in distributed databases, plus any other supplier that
produces them, e.g. ORACLE and INGRES.
Any texts providing information about synchonicity between computers
and networks. To be found.
1.20.8 Year 2000 references
General info. about ISO 8601
http://ourworld.compuserve.com/homepages/dstrange/y2k.htm
setting up PCs to work in ISO 8601 format:
www.aegis1.demon.co.uk/y2k/iso-pc.htm
List of standards associated with ISO 8601
http://www.aegis1.demon.co.uk/y2k/isoimp.htm
Scientific American, January 1999 - "Y2K: So Many Bugs ... So
Little Time" by Peter de Jager.
Peter de Jager's web site - www.year2000.com
YEAR 2000 volumes 1 & 2, published by the BCS
GC28-1251-08 - "The Year 2000 and 2-digit Dates - A guide for
planning and implementation". Published by IBM.
2 Ideas and Work in progress
Not that the preceding is necessarily complete or correct.
It is a good idea to itemise and discuss all the problems associated
with dates and times before considering potential solutions in detail,
certainly before they are finalised.
2.1 Leap seconds and durations
In a sense, administrative time is usually regarded/treated as not
having leap seconds, though for accurate interval measurement they can't
be ignored. Perhaps this is the clue to appropriate handling for
administrative purposes. Provided computers just interpolate a second's
delay in their activities on behalf of those programs that don't need
accurate intervals, it would be possible to pretend they never happen,
which in most commercial systems seems to be the case at present. Leap
seconds have been applied in most years since 1972, so there is and has
been the possibility of durations being calculated incorrectly with
possibly significant implications, albeit very rarely. However, most
commercial applications work in units of days, weeks, months and years for
which these problems don't apply, provided arithmetic is based upon dates
first derived from timestamps rather than timestamps alone.
2.2 Calculations involving months
Arithmetic using months is very tricky and best avoided when possible.
For example, if one adds one month to the 30th of April, one gets the 30th
of May, which may not be what is desired, whereas when doing the same for
the 12th of April one would almost certainly want the result to be the
12th of May. Adding one month to the 31st January gives the 28th or
29th February in DB2 version 3 and probably 4, which is flagged with a
warning, leaving it up to the programmer to make the appropriate
adjustment, which may vary depending on circumstances as the last day of
February or the 2nd or 3rd of March may be required - to be checked
further. - ANSI 1992 SQL just adds one month to the month component, which
can result in an invalid day value. (I don't yet know whether a non-zero
SQLSTATE is raised for this condition.) The safest way to obtain the
last day of the current month of a date is, within a single SQL statement,
to extract the month and year of the date in question, append the literal
01 for the day, add one month, then subtract one day. There isn't a safe
consistent way to add a month to a date that has a day greater than the
27th, as the need may vary, for example when adding one month to the 29th
February different circumstances may require the 29th March or 31st March.
Dependent on the nature of their business, some commercial organisations
can avoid the problem by not allowing any recurring transactions to be
dated for days greater than the 28th of a month.
2.3 Practice and thoughts on Timestamp arithmetic
select '1997-03-13-10-05-00.000000' - '1996-04-01-12-25-03.000000'
into hostv1 (dt TIMESTAMP) (where dt = datatype)
DB2 version 4 allows one timestamp to be subtracted from another
producing a result that is a duration in TIMESTAMP format. However, it is
questionable what one could do with such a duration. It can not safely be
converted to a number of days or seconds, nor can it be safely compared
with another duration derived from another pair of dates.
ANSI SQL 1992 defines INTERVAL data types and has rules as to how they
may be combined to form compound datatypes, i.e. YEAR and MONTH may be
paired and any contiguous combination of DAY, HOUR, MINUTE and SECOND may
be combined. These datatypes do have minimum and maximum levels of
permissible precision. Seconds are the only datatypes that may have
decimal places.
2.4 Accuracy indicators
Maybe there should be an indicator eight bit byte to show how close to
UTC the timestamp is. Its setting would be determined by the date routine
process according to how recently UTC time was obtained and how accurate
the computer's internal clock is. Date routine processes within a computer
operating system could regularly check their own timekeeping accuracy
through regular access to UTC. In this way they could determine the
maximum time allowed between UTC checks during which their own internal
timekeeping could be regarded as acceptably accurate. At some point in the
not too distant future, a computer could perhaps be designed not to
generate timestamps at all after power up, until UTC time had been
obtained. There would have to be exceptions to allow system recovery in
deep space, down mines, undersea, radio malfunction, etc. Perhaps yet
another indicator bit would be required to identify such timestamps. Maybe
an eight bit byte should be used, progressive settings of which would
indicate the level of coordination with UTC. A value of zero would
indicate no coordination at all, though such timestamps would still be
self consistent, a value of one might indicate that the timestamp was
within an hour of UTC adjusted by timezone, two might be within 30
minutes, three within 15 minutes, four within 8 minutes, five within 4
minutes, six within 2 minutes, seven within 1 minute, eight within 30
seconds, nine within 15 seconds, ten within 8 seconds, eleven within 4
seconds, twelve within 2 seconds, thirteen within one second, etc. Because
regular improvements in UTC timekeeping and system coordination can be
expected in the future, I would think that the accuracy level for
currently conforming systems should not be set to the maximum, but instead
such as to provided a generous margin for future improvements. There are
256 different values available from an eight bit byte, so there would
still be plenty of room for considerable differentiation between accuracy
levels, even if one started by just using the first 64. The scale of
division could be linear or logarithmic. A scale using multiples of
seconds to the power of ten might be preferable, where the exponent could
be both positive and negative.
The SQL standard already provides a facility for time zones, which are
adjusted as necessary for daylight saving time.
I since found that a component of time as defined for UTC, is the
specification of the inaccuracy in 100 nanosecond units. While appropriate
for some systems, this does not provide for the same range of inaccuracy
as the scheme described above.
2.5 Delay in application of timestamps
Although a time or timestamp may have been obtained with very high
accuracy, by the time it has been applied by a program there may have been
some significant delay, either because of other normal work by the program
or because of resource contention. The time that a program is allowed to
wait due to contention with other activities is indeterminate, but could
be limited by system parameters. This may be of particular concern when
saving the current timestamp for later use. It is probably fair to say
that in most commercial situations high accuracy for timestamps stored in
data is not really required, provided that timestamps are unique, so that
they can be used to determine the order in which operations have been
applied. Timestamps are often also used to help identify related items.
Accurate durations might be more important. However, where distributed
systems are concerned, synchrony can be important. Even when a timestamp
is set directly by the SQL subsystem, because of delays arising from use
of a multitasking operating system, it may still not be applied
immediately.
2.6 Julian Days
The first Julian Period started at noon on January 1st 4713 BC with day
0.0. The current intention appears to be to continue the period
indefinitely.
A Julian date refers to the use of the Julian calendar not to Julian
days.
There is no year 0. Year 1 B.C. immediately precedes year 1 A.D. in both
Julian and Gregorian calendars.
Backwards extrapolation from A.D. 1582 is done with the Julian calendar.
Individual countries that made the transition later must make
corresponding adjustments.
The Julian day JD 2,451,545.0 UT is equivalent to the Gregorian calendar
date noon on 1st January 2000.
The Julian day JD 2,439,816.0 UT is equivalent to the Gregorian calendar
date noon on 21st November 1967.
The Julian day JD 2,444,923.0 UT is equivalent to the Gregorian calendar
date noon on 14th November 1981.
A modified Julian day is derived by subtracting 2,400,000.5 from a
Julian day, this gives a change of day at midnight.
2.7 Potential date/time and duration representation
All representations could be expressed as based upon UTC or local
processor clock time. Refer also to ISO 8601.
I generally concur with the approach taken by SQL, though there is a
need for a wider range of datatypes, while interval datatypes are not
entirely satisfactory. Perhaps the SQL datatypes of date, time and
timestamp should be regarded as primary basics. On the other hand Julian
days or TAI might be a better primary basic. Standard conversion
mechanisms between formats would also be needed.
In SQL, date/time datatypes that are singular are considered to be dates
or times, while plurals are considered to be durations. This is a useful
convention and could be adhered to strictly.
2.7.1 Durations
durations associated with a specific start or end date will include both
leap years and leap seconds
durations not associated with a specific start or end date will have
years of 365 days, months of 30 days (except that 12 months = 365 days)
and minutes of 60 seconds. This is not really satisfactory. ISO 8601 uses
a 360 day year for its alternate definition of a duration.
seconds (SI definition)
days (mean solar days as defined administratively) (UTC)
years (tropical years as defined administratively) (UTC)
combinations of units (ref. SQL intervals)
2.7.2 Dates and Times
date representations
(all to be based on the Gregorian calendar)
yyyy
yyyy-mm
yyyy-mm-dd
yyyy-ddd
yyyy-w
yyyy-w-d
Julian day (JD)
Modified Julian day (MJD)
"Julian" week (MJW ?)
calendar representations
Gregorian, Julian, UTC-second, Hebrew, Muslim, Hindu, Buddhist, Chinese,
Japanese, Julian-day, modified-Julian-day, etc. To be encoded with three
letter abbreviations, similar, yet distinct from the ISO codes used for
representation of countries. Though for Muslim countries, there may also
need to be a country code.
time representations
second
minute
hour
day ?
combined dates and times
timestamp as per 1992 SQL and ISO 8601
pure second - normally UTC
Provision of commonly required functions
These would probably be of two major groups, conversion functions and
special purpose functions. - plus duration calculations and comparisons
????
COBOL provides a number of conversion functions, presumably so do many
other languages.
Special purpose functions could include mechanisms for determining bank
holidays, number of working days between two dates, distinguishing working
days from weekends, etc.
Even with a standard base set of functions, there would presumably be special requirements for particular organisations. Nevertheless provision of a base set could be an asset.
3 Correspondence
not included in this document